On Jan 29, 2023, at 4:45 PM, Warner Losh &lt;imp(a)bsdimp.com&gt; wrote: On Sun, Jan 29, 2023, 3:59 PM Bakul Shah &lt;bakul(a)iitbombay.org <mailto:bakul@iitbombay.org>> wrote: Because if it is closed the first open will return 1. And that's also where the printf will go...

Warner > Anyway, this sounds like a classic case of "the confused deputy". > http://www.cap-lore.com/CapTheory/ConfusedDeputy.html > > Of course, a tighter security design might've made it much more difficult to apply useful hacks like the one Mike Muus did! > >> On Jan 29, 2023, at 11:39 AM, Ron Natalie &lt;ron(a)ronnatalie.com <mailto:ron@ronnatalie.com>> wrote: >> >> 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. >