Sometimes after looking at web application security, IoT botnets, and various malware I long for the pre-2000 hacking days. Where, instead of looking for XSS or SQL injection vulnerabilities, you would be hunting for server-side vulnerabilities. This summer, I was gifted an SGI Indy R5000. I’d mentioned on Twitter a while back that I’d love to have an IRIX system in my lab, since this was the system I’d discovered my first vulnerability on, CVE-1999-0765. Someone who follows me on Twitter asked me to message him privately since he had an SGI system laying around in his maker space.
The system he gave me is an SGI Indy R5000. He had all the original manuals and CD packs that came with it while it was under full support from its previous owner. The system has 64MB of RAM and a 1GB disk. Yes, that’s Megabytes of RAM. I had the system upgraded to 128MB of RAM and a 30GB disk by ordering parts from an SGI enthusiast in the UK.
The operating system SGI IRIX 6.5.22 was declared end of life in 2003, so it has limited use as a production system. I decided I could relive the good old days by looking for new vulnerabilities on an old system in my spare time. It was also an excuse to write some C code, and refresh my memory.
One of my favorite vulnerabilities is the Insecure Temporary File (CWE-377). This involves manipulating files created in /tmp in an insecure manner. A file is created in /tmp by a piece of software that doesn’t check if the file exists before creating it. Allowing a malicious local user to symlink that file to a critical system file and overwriting it with the contents of what is written to the file in /tmp.
So I started looking under the /usr/sbin directory for binaries to target. I did a quick examination of binaries and scripts in using the find command to give myself a starting point.
The command I used is:
$ find . -type f -exec grep -l “/tmp” {} \;
This command looks at all files in the current directory, listing ones where it finds the string “/tmp”.
Some exploitation scenarios are if the root user is running a vulnerable program that simply writes to the /tmp directory without checking that the file exists first, we can clobber system files by creating a symlink from that file to a critical system file like /etc/passwd and create a DoS-like scenario. If the root user is executing a program that writes to the /tmp directory and uses that file to create an entry in crontab or build a shell script and execute it, we can possibly inject our own command or code in there to elevate our own system privileges.
A good deal of developers used the process ID as a way to create a unique file name in /tmp. The problem with this is the number of possible processes on a system is a finite and relatively small number. This is less common today as developers use solutions like mkstemp(), mktemp and other functions to create an area in /tmp where files can be manipulated safely.
Test exploitation code:
https://github.com/lcashdol/symlinker
The l0pht-watch code originally written by Mudge and tweaked by me for IRIX.
https://github.com/lcashdol/l0pht-watch
An example run of the symlinker code that I wrote:
larry@mathom:~/code/symlinker$ ./symlink -n 10 -f to_dos# -t /etc/passwd
Starting from our own process id: 259857
Symlinking /tmp/to_dos259857->/etc/passwd /tmp/to_dos259858->/etc/passwd /tmp/to_dos259859->/etc/passwd /tmp/to_dos259860->/etc/passwd /tmp/to_dos259861->/etc/passwd /tmp/to_dos259862->/etc/passwd /tmp/to_dos259863->/etc/passwd /tmp/to_dos259864->/etc/passwd /tmp/to_dos259865->/etc/passwd /tmp/to_dos259866->/etc/passwd
/tmp/to_dos259867->/etc/passwd
Waiting on a write to one of our predicted links in /tmp or pid to grow past the links we created.
[+] The target file /etc/passwd has been overwritten!
[+] Modification time changed from Fri Oct 25 13:31:44 2019 to Sun Oct 27 02:39:16 2019
Cleaning up….
Unlinking -> /tmp/to_dos259867 /tmp/to_dos259866 /tmp/to_dos259865 /tmp/to_dos259864 /tmp/to_dos259863 /tmp/to_dos259862 /tmp/to_dos259861 /tmp/to_dos259860 /tmp/to_dos259859 /tmp/to_dos259858 /tmp/to_dos259857
So what happened? The symlinker tool creates a block of consecutively numbered symlinks using the pid of the symlinker tool as a starting point (since it was the latest program executed)* it does this attempting to already have a link in place that matches the filename being created by our vulnerable script.
If we look at /etc/passwd it has been overwritten with the file root user was attempting to convert from DOS to UNIX. This is a simple DoS attack against the users of the operating system as writing over /etc/passwd will prevent other users from logging in. If IRIX 6.5.22 had not been declared End of Life in 2003 I would have issued this vulnerability a CVE ID and submitted it to Hewlett Packard, the current owner of SGI as of May 2019.