[TUHS] File descriptor fun and games (setuid)

[TUHS] File descriptor fun and games (setuid)

[Ron Natalie]

[-- 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 --]

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

[Bakul Shah]

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

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?

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: 9574 bytes --]

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

[Warner Losh]

[-- 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 --]

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

[Bakul Shah]

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



> On Jan 29, 2023, at 4:45 PM, Warner Losh <imp@bsdimp.com> wrote:
> 
> 
> 
> On Sun, Jan 29, 2023, 3:59 PM Bakul Shah <bakul@iitbombay.org <mailto: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...

I got that far but didn't think further (open to read the superblock will be now on fd 1).
Thanks! Definitely a confused deputy problem! 

> 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 <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.
>> 


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