[TUHS] File descriptor fun and games (setuid)
Warner Losh
imp at bsdimp.com
Mon Jan 30 10:45:43 AEST 2023
On Sun, Jan 29, 2023, 3:59 PM Bakul Shah <bakul at iitbombay.org> wrote:
> Sorry for nitpicking but I don't understand why closing fd 1 *before*
> calling mount result in this behavior? Shouldn't a write(1, ...) just fail?
>
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 <ron at 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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230129/a99f4980/attachment.htm>
More information about the TUHS
mailing list