[TUHS] Re: File descriptor fun and games (setuid)

[Warner Losh <imp@bsdimp.com>]

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

On Sun, Jan 29, 2023, 3:59 PM Bakul Shah <bakul@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@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.
>
>
>

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