By Bri Hatch.
Summary: /bin/rm doesn't mean remove, it means unlink, and it has security repercussions.
In a previous article
I described a machine compromise that initially would seemed to
have been impossible. A vulnerable suid root program,
So, how can it be that a program can be accessed even after it's been removed? The problem is that it wasn't removed.
When we access a file on disk, we do so by providing a filename
for it. The filesystem uses filenames, which are simply entries
in directories, to look up the file's inode. An inode is a uniq
essentially a file number, which identifies the file on that
filesystem. You can see the inode with the
$ ls -il /bin/cat 32689 -rwxr-xr-x 1 root root 13912 Sep 17 06:54 /bin/cat
That first number in the second line is the inode number, here
$ ls -il /bin/gzip 32755 -rwxr-xr-x 4 root root 13912 Apr 19 04:43 /bin/gzip
Note that link count of 4 in this case. How can we find the other
filenames that point to this same file? First, let's determine which
$ cd /bin $ df . Filesystem 1K-blocks Used Available Use% Mounted on /dev/hda5 10766920 8325216 1894740 82% / $ find / -inum 32755 -xdev -ls 2>/dev/null 32755 56 -rwxr-xr-x 4 root root 13912 Apr 19 04:43 /bin/gzip 32755 56 -rwxr-xr-x 4 root root 13912 Apr 19 04:43 /bin/gunzip 32755 56 -rwxr-xr-x 4 root root 13912 Apr 19 04:43 /bin/zcat 32755 56 -rwxr-xr-x 4 root root 13912 Apr 19 04:43 /bin/uncompress
Here we can see that the four files,
We call these hard links -- when a file on disk is available via separate filenames. Compare these to symlinks/softlinks, which are separate files that point to a filename, rather than an inode:
$ ls -il /bin/nc /bin/netcat 32502 -rwxr-xr-x 1 root root 19352 Oct 13 15:20 /bin/nc 51222 lrwxrwxrwx 1 root root 2 Oct 13 15:20 /bin/netcat -> nc
Now anyone can make a hard link or symlink, assuming they have write permission to a directory. While symlinks can cross filesystem boundaries (they point to file names, not inodes) a hard link can only be created on the filesystem where the target file resides.
Thus to create a hard link to
So what happened? The attacker created a link to
attacker$ cd $HOME attacker$ ls -il /usr/sbin/buggy 18824 -rwsr-xr-x 1 root root 19352 Feb 5 08:12 /usr/sbin/buggy attacker$ ln /usr/sbin/buggy mybuggy.hardlink attacker$ ls -il /usr/sbin/buggy mybuggy.hardlink 18824 -rwsr-xr-x 2 root root 19352 Feb 5 08:12 /usr/sbin/buggy 18824 -rwsr-xr-x 2 root root 19352 Feb 5 08:12 mybuggy.hardlink
Note how the link count has changed to 2 now -- this file on disk is now referenced by two filenames.
Later on, when the bug in
attacker$ ls -il /usr/sbin/buggy mybuggy.hardlink 45110 -rwsr-xr-x 1 root root 17889 Nov 29 12:13 /usr/sbin/buggy 18824 -rwsr-xr-x 1 root root 19352 Feb 5 08:12 mybuggy.hardlink
That first file is the new, non-vulnerable
So, how should the administrators have known that this link was still hanging around? There are several precautions that would have indicated or prevented the problematic situation:
Several readers had other ideas of how this could have been caused. I'll cover some of them in following articles, as they are all interesting.
Congrats go to Jim Richardson of Seattle, WA for solving the contest, thus winning a signed copy of Hacking Linux Exposed Second Edition.
 Yeah, it would have made much more sense for the attacker to put other backdoors into the system. I'm just concentrating on this one hole because anything else would be extraneous.
Bri Hatch is Chief Hacker at Onsight, Inc and author of Hacking Linux Exposed and Building Linux VPNs. He was pleasantly surprised that the contest winner was a fellow Seattlite. Besides, then he was able to save money on postage. Bri can be reached at firstname.lastname@example.org.
Copyright Bri Hatch, 2003
This is the December 14, 2003 issue of the Linux Security: Tips, Tricks, and Hackery newsletter. If you wish to subscribe, visit http://lists.onsight.com/ or send email to Linux_Securityemail@example.com.