[TUHS] File descriptor fun and games (setuid)

["Ron Natalie" <ron@ronnatalie.com>]

[-- Attachment #1: Type: text/plain, Size: 3572 bytes --]

Another of Ron’s historical diversions that came to mind.

Most of you probably know of various exploits that can happen now with 
setuid programs, but this was pretty loose back in the early days.   I 
was a budding system programmer back in 1979 at Johns Hopkins.   Back 
then hacking the UNIX system was generally considered as sport by the 
students.   The few of us who were on the admin side spent a lot of time 
figuring out how it had happened and running around fixing it.

The first one found was the fact that the “su” program decided that if 
it couldn’t open /etc/passwd for some reason, things must be really bad 
and the invoker should be given a root shell anyhow.   The common 
exploit would be to open all the available file descriptors (16 I think 
back then) and thus there wasn’t one available.   That was fixed before 
my time at JHU (but I used it on other systems).

One day one of the guys who was shuffling stuff back and forth between 
MiniUnix on a PDP-11/40 and our main 11/45 UNIX came to me with his RK05 
file system corrupted.   I found that the superblock was corrupted.   
With some painstaking comparison to another RK05 superblock, I 
reconstituded it enough to run icheck -s etc.. and get the thing back.   
What I had found was that the output of the “mount” command had been 
written on the superblock.   WTF?  I said, how did this happen.   
Interrogating the user yielded the fact that he decided he didn’t want 
to see the mount output so he closed file descriptor one prior to 
invoking mount.   Still it seemed odd.

At JHU we had lots of people with removable packs, so someone had 
modified mount to run setuid (with the provision of only allowing 
certain devices to be mounted certain places).   At his point we had 
started with the idea of putting volume labels in the superblock to 
identify the pack being mounted.    Rather than put the stuff in the 
kernel right away, Mike Muuss just hacked reading it from the super 
block in the usermode mount program so that he could put the volume 
label in /etc/mtab.   Now you can probably see where this is headed.   
It opens up the disk, seeks to the pack label in the superblock and 
reads it (for somereason things were opened RW).  Then the output goes 
to file descriptor 1 which just happens to be further in the superblock.

I figured this out.   Fixed it and told Mike about it.   I told him 
there were probably other setuid programs around that had the problem 
and asked if it was OK if I hacked on things (at the time I yet was not 
trusted with the root password).   He told me to go ahead, knock 
yourself out.

Well I spent the evening closing various combinations of file 
descriptors and invoking setuid programs.   I found a few more and noted 
them.    After a while I got tired and went home.

The next day I came in and looked through our paper logbook that we 
filled out anytime the machine was shutdown (or crashed).   There was a 
note from two of the other system admins saying they had shut the system 
down to rebuild the accounting file (this was essentially the shadow 
password file and some additional per-user information not stored in 
/etc/passwd).   The first 8 bytes were corrupted.    Oh, I say, I think 
I might know how that happened.   Yeah, we thought you might.   Your 
user name was what was written over the root entry in the file.    The 
passwd changing program was one of the ones I tested, but I hadn’t 
noticed any ill-effects for it at the time.

[-- Attachment #2: Type: text/html, Size: 4504 bytes --]