Closing suid root security holes forever

Closing suid root security holes forever

Post by Thomas Koen » Fri, 02 Dec 1994 08:14:50



It would seem that a large class of UNIX security holes are based
on tricking some suid program into writing to files which it's
not supposed to.

Swapping euid and uid works, but is error - prone (out of 100
opens, you'll probably only secure 99).

I would suggest adding a special file type to make this impossible.
Suppose we have a special bit associated with each file (let's
call it the "system bit"), turned on for all security - related
files (/etc/passwd, /etc/hosts.equiv, /etc/inetd.conf, ...)

The system insures that they have to be opened with a special
flag for writing, say with

    open("/etc/passwd", O_RDWR | O_SYSTEM);

Unless the O_SYSTEM flag is present, all processes (including, and
especially those with root privileges) get 'permission denied'.

This would mean that a cracker who has subverted some suid root
program into appending a new root id to /etc/passwd won't
succeed, because said suid root program won't open any random
file with that flag set.

Programs like 'useradd', 'userdel' etc. will open /etc/passwd with
this flag, but those won't be userid root; the most common editors
could be patched easily to detect the presence of this flag.

Bang, goes one class of security risks inherent in UNIX systems.

This would seem to be such a trivial hack to, let's say, Linux, that
I'd be surprised if nobody had thought of this before; yet, at least
on the UNIX systems I know, nobody does this.  (I once heard something
about BSD 4.4 implementing something called 'immutable files', which
may be related, but I dont't know BSD 4.4).

Comments?
--

The joy of engineering is to find a straight line on a double
logarithmic diagram.

 
 
 

Closing suid root security holes forever

Post by Andre Fach » Fri, 02 Dec 1994 19:34:06


: The system insures that they have to be opened with a special
: flag for writing, say with

:     open("/etc/passwd", O_RDWR | O_SYSTEM);

: Unless the O_SYSTEM flag is present, all processes (including, and
: especially those with root privileges) get 'permission denied'.

: This would mean that a cracker who has subverted some suid root
: program into appending a new root id to /etc/passwd won't
: succeed, because said suid root program won't open any random
: file with that flag set.

: Programs like 'useradd', 'userdel' etc. will open /etc/passwd with
: this flag, but those won't be userid root; the most common editors
: could be patched easily to detect the presence of this flag.

Hm, then I write a programm, without uid root, write a line of code
like open("/etc/passwd", O_RDWR | O_SYSTEM) and the system will open
the file for me?
This seems to me a much bigger bug than before...

Andre

--

For some it is MS-Windows, for others it's the longest batch file on earth...

 
 
 

Closing suid root security holes forever

Post by Casper H.S. D » Fri, 02 Dec 1994 22:31:38



>It would seem that a large class of UNIX security holes are based
>on tricking some suid program into writing to files which it's
>not supposed to.
>Swapping euid and uid works, but is error - prone (out of 100
>opens, you'll probably only secure 99).

The trick of swapping uids is not to swap the uids before and after all
opens, the trick is to swap it at the start of the program and swap
it again before the part of the code you need the extra permissions
for.  You can't miss an open that way.

Quote:>The system insures that they have to be opened with a special
>flag for writing, say with
>    open("/etc/passwd", O_RDWR | O_SYSTEM);

Right, and we'll have to rewrite *all* utilities we commonly use
to "grok" system files to use O_SYSTEM because we can't use
awk, sed, perl, the shell, vi, emacs, etc anymore to fix system files?

Soon after all programs will be modified to add O_SYSTEM and
we're back were we started.

Casper

 
 
 

Closing suid root security holes forever

Post by Leslie Gil » Sat, 03 Dec 1994 05:07:18




|>
|> >It would seem that a large class of UNIX security holes are based
|> >on tricking some suid program into writing to files which it's
|> >not supposed to.
|>
|> >Swapping euid and uid works, but is error - prone (out of 100
|> >opens, you'll probably only secure 99).
|>
|> The trick of swapping uids is not to swap the uids before and after all
|> opens, the trick is to swap it at the start of the program and swap
|> it again before the part of the code you need the extra permissions
|> for.  You can't miss an open that way.
|>
|> >The system insures that they have to be opened with a special
|> >flag for writing, say with
|>
|> >    open("/etc/passwd", O_RDWR | O_SYSTEM);
|>
|> Right, and we'll have to rewrite *all* utilities we commonly use
|> to "grok" system files to use O_SYSTEM because we can't use
|> awk, sed, perl, the shell, vi, emacs, etc anymore to fix system files?
|>
|> Soon after all programs will be modified to add O_SYSTEM and
|> we're back were we started.

And in any case there are other problems with setuid programs...  Try
setting a link (hard or soft) to a setuid script, then start executing
the script - the OS will notice that it is a script, will start up a
shell with the new uid, and will pass the file to the new shell.  The
trick is to change the link to point to your own shell script after Unix
has created the new shell and before the new shell has opened the
script file.

Or alternatively explore the more interesting uses of setting $IFS
to '/', then calling a setuid program that uses something like
system("/bin/ls") (although most newer shells reset $IFS when they're
started just to prevent this).

There are many security problems with setuid programs.  Unfortunately
I think there's a law coming into effect here - any "sufficiently
powerful" system cannot be secure, and any secure system will not be
"sufficiently powerful" (to borrow from Godel's theorem).

Lezz Giles

 
 
 

Closing suid root security holes forever

Post by Phil Howa » Sat, 03 Dec 1994 06:12:19



>Hm, then I write a programm, without uid root, write a line of code
>like open("/etc/passwd", O_RDWR | O_SYSTEM) and the system will open
>the file for me?
>This seems to me a much bigger bug than before...

No.  The program ALSO has to have the usual permissions.  This idea
is adding another layer to the security.  You still have to have the
program run from root or as suid root.  The O_SYSTEM flag would be
ignored for non-root.  The idea is that if a root program does NOT
have the flag set, it is saying to the kernel "make this fail if the
file does not have the system flag set".

While I don't see a problem with it, and suspect there will be some
gain in security, I would not say it closes all holes.
--
Phil Howard KA9WGN      | Intel says that in most cases the divide bug in the
Unix/Internet/Sys Admin | Pentium will not be noticed.  Does that include the
CLR/Fast-Tax            | engineer who designs the bridge you will drive over

 
 
 

Closing suid root security holes forever

Post by D. J. Bernste » Sat, 03 Dec 1994 09:33:23



> There are many security problems with setuid programs.  Unfortunately
> I think there's a law coming into effect here - any "sufficiently
> powerful" system cannot be secure, and any secure system will not be
> "sufficiently powerful" (to borrow from Godel's theorem).

I disagree. Power and security are almost entirely orthogonal.

Let me state the obvious. In any system certain pieces of code are
_security-relevant_. (In UNIX this means the kernel, setuid programs,
programs run by root, programs which give users the power to unwittingly
hurt their own security, etc.) In a supposedly secure system, any
security hole is, by definition, a bug. Obviously the code containing
the bug is security-relevant.

Any sufficiently large piece of code has bugs. More code means more
bugs. A bug in security-relevant code has a 7% chance of causing a
security hole. (I made up the 7%, but you get the idea.)

Do you want more security holes in your system? Easy: just add more
security-relevant code. The reason that there are many security problems
with setuid programs is simply that there are _so many_ setuid programs
with _so much_ security-relevant code.

Conversely, the first and most important step towards a secure system is
to minimize the amount of security-relevant code. You can do this no
matter how much ``power'' the system provides.

---Dan

 
 
 

Closing suid root security holes forever

Post by S. Joel Ka » Sat, 03 Dec 1994 17:41:52




>: The system insures that they have to be opened with a special
>: flag for writing, say with
>:     open("/etc/passwd", O_RDWR | O_SYSTEM);
>: Unless the O_SYSTEM flag is present, all processes (including, and
>: especially those with root privileges) get 'permission denied'.
>: This would mean that a cracker who has subverted some suid root
>: program into appending a new root id to /etc/passwd won't
>: succeed, because said suid root program won't open any random
>: file with that flag set.
>: Programs like 'useradd', 'userdel' etc. will open /etc/passwd with
>: this flag, but those won't be userid root; the most common editors
>: could be patched easily to detect the presence of this flag.
>Hm, then I write a programm, without uid root, write a line of code
>like open("/etc/passwd", O_RDWR | O_SYSTEM) and the system will open
>the file for me?
>This seems to me a much bigger bug than before...
>Andre

        No, it won't open the file for you because you don't have write
privileges to it.

--

S. Joel Katz            Information on Objectivism, Linux, 8031s, and more

        Time flies like an arrow -- fruit flies like a banana.

 
 
 

Closing suid root security holes forever

Post by S. Joel Ka » Sat, 03 Dec 1994 17:43:38




>>It would seem that a large class of UNIX security holes are based
>>on tricking some suid program into writing to files which it's
>>not supposed to.
>>Swapping euid and uid works, but is error - prone (out of 100
>>opens, you'll probably only secure 99).
>The trick of swapping uids is not to swap the uids before and after all
>opens, the trick is to swap it at the start of the program and swap
>it again before the part of the code you need the extra permissions
>for.  You can't miss an open that way.
>>The system insures that they have to be opened with a special
>>flag for writing, say with
>>    open("/etc/passwd", O_RDWR | O_SYSTEM);
>Right, and we'll have to rewrite *all* utilities we commonly use
>to "grok" system files to use O_SYSTEM because we can't use
>awk, sed, perl, the shell, vi, emacs, etc anymore to fix system files?
>Soon after all programs will be modified to add O_SYSTEM and
>we're back were we started.
>Casper

        Actually, some genius will come up with a new process flag the
appends O_SYSTEM to all file accesses for a sub-process. Scripts will be
hacked to use this program (syntax similar to 'time' or 'nohup'). And
_THEN_ we'll be back where we started.

--

S. Joel Katz            Information on Objectivism, Linux, 8031s, and more

        Time flies like an arrow -- fruit flies like a banana.

 
 
 

Closing suid root security holes forever

Post by Thomas Koen » Sat, 03 Dec 1994 08:03:01





>>The system insures that they have to be opened with a special
>>flag for writing, say with
>>    open("/etc/passwd", O_RDWR | O_SYSTEM);
>Right, and we'll have to rewrite *all* utilities we commonly use
>to "grok" system files to use O_SYSTEM because we can't use
>awk, sed, perl, the shell, vi, emacs, etc anymore to fix system files?
>Soon after all programs will be modified to add O_SYSTEM and
>we're back were we started.

I doubt that, to use a recent example, sendmail will be configured to
open its logfiles with O_SYSTEM :-)
--

The joy of engineering is to find a straight line on a double
logarithmic diagram.
 
 
 

Closing suid root security holes forever

Post by Thomas Koen » Sat, 03 Dec 1994 08:07:05






>In newsgroup: comp.os.linux.development

>> Hm, then I write a programm, without uid root, write a line of code
>> like open("/etc/passwd", O_RDWR | O_SYSTEM) and the system will open
>> the file for me?
>> This seems to me a much bigger bug than before...

>No, you would of course have to be root as well.
>Of course, this hack only makes it more burdensome, but it will make
>it no harder for a hacker to gain full root privileges than without.

This depends.  There are several security holes that I'm aware of
which would not be exploitable with this scheme.

Quote:>It just takes leaving a shell script somewhere that will get executed
>by some root process (hint: leave something in /bin that parallells
>something in /usr/bin; odds are that at least some program will
>mistake'm)... BANG... you're dead.  No benefit.

Ahem... if your system administrator does leave /bin open, you've got
another path of attack to worry about :-)
--

The joy of engineering is to find a straight line on a double
logarithmic diagram.
 
 
 

Closing suid root security holes forever

Post by Wietse Vene » Sun, 04 Dec 1994 06:20:04


Quote:>Do you want more security holes in your system? Easy: just add more
>security-relevant code. The reason that there are many security problems
>with setuid programs is simply that there are _so many_ setuid programs
>with _so much_ security-relevant code.

Many set-uid programs such as login, su and sendmal invoke other
commands.  There is a lot of code that was never intended to be called
from set-uid programs.  And don't overlook networking and other forms
of inter-process communication. They are just set-uid in disguise.

        Wietse

 
 
 

Closing suid root security holes forever

Post by Olaf Kir » Sat, 03 Dec 1994 09:40:51


: I would suggest adding a special file type to make this impossible.
: Suppose we have a special bit associated with each file (let's
: call it the "system bit"), turned on for all security - related
: files (/etc/passwd, /etc/hosts.equiv, /etc/inetd.conf, ...)

Tricking suid root programs to append to sensitive files is only one
part of the problem. You can cause as much trouble when creating files
where you're not supposed to create them, like at jobs, trojan horses,
etc. And you can't put a magic bit on a file that's not there:)

Olaf
--
Olaf Kirch        | Sometimes I lie in bed at night, and I ask myself: ``Why?''

                                                            -- Charlie Brown

 
 
 

Closing suid root security holes forever

Post by Pascal Haib » Sat, 03 Dec 1994 19:44:27




[...]

Quote:>The reason that there are many security problems
>with setuid programs is simply that there are _so many_ setuid programs
>with _so much_ security-relevant code.

While many suid programs don't have to be suid. I once saw a Linux
distribution where the manual stated 'if you have problems with mtools
not being able to open the floppy device, make the mtool programs suid'.

Many people don't know how to use groups and the sgid bit (they are
used suns, where there is no obvious scheme in using the groups -
root, wheel, staff, bin, daemon,...).
If you want your mtools to be able to open the floppy device (or a hard
disk device) without the users having direct write access to the device,
make the motools programs sgid 'mtools', chgrp mtools /dev/fd*, and
give some users the group mtools. As no other directory or file
belongs to mtools, no extra security risk is added.
Or take the kmem ps (assuming it is name kmem-ps): chgrp kmem /dev/kmem ;
chmod 440 /dev/kmem ; chgrp kmem kmem-ps ; chmod g+s kmem-ps.

This is a trivial thing to me, but apparently not to everyone.

Pascal

 
 
 

Closing suid root security holes forever

Post by Roland Mei » Sun, 04 Dec 1994 00:46:03



Quote:> While many suid programs don't have to be suid. I once saw a Linux
> Many people don't know how to use groups and the sgid bit (they are

Or what to apply them to: One point I'd like to mention here is the necessity
for all programs that use the SVGALIB to be suid root. This not only increases
the security risk (according to D. Bernstein), it also prevents any non-root
from installing such a program.

Wouldn't it be better to make them SGID svga and the questionable device (BTW:
which one is it?) writable for that group? That wouldn't make it installable by
a user, but may be safer for root to make a chgrp;chmod g+s

Maybe a little off-topic, sorry...
--
===============================================================================


D-63322 Roedermark                    ... we all live in a yellow subroutine :>
===============================================================================

 
 
 

1. Security Hole on webservers run on variuos OS, How to close UNIS hole

Hi,

I have written a program that enables me via the web, to access any file
(access is see it and download it) on a webservers hard drive. It
basically exlpores the drive (/ root downwards). Now the Apache Server
that run my program delivers the results to my browser. I wrote it
initailly to test the security of our account.

So what permissions should I use on our web directory:-

/usr/www/foobar

That will still allows the server to deliver the webpages and yet stop
people from other accounts from accessing it via chdir (telnet/ftp)?

We also hove home directoys that are not visible to the www called:-
/usr/home/foobar

Now my programs can access this directory too! So what sould I set the
file permissions too, again to stop other account holders with our ISP
from accessing it?

For the record my program traversed the enitire Disc that the web server
is running on. It was only denied access to a few directorys.

Also this mean that no logs are kept!! As my 2nd program called by the
first program, downloads the actual file to my browser and the only log
kept ofcousre is that someone ran the download program.

Is this what Goverments do to obtain without permission peoples files?:-

Say they are targetting http://www.foobar.co.uk, they can do this:-

1) Find out who the ISP is for http://www.foobar.co.uk
2) Buy a cgi account with the same ISP
3) Use a program like mine. (Will not give details publically)
4) Run the program and download the files including any within NON web
directorys.
--
Mark Worsdall
Home  :- shadowwebATworsdall.demon.co.uk
Any opinion given is my own personal belief...

2. Boot Error Message

3. best-of-security mailing list (was: Solaris 2.5 Security Hole: local users can get root)

4. 3COM 3C590 PCI

5. why are suid script a security hole

6. Swat Problem

7. Solaris Security Hole -- uudecode can create SUID files

8. Question: How to use NIS+ or NIS in a alread established Network

9. HUGE security hole ! How to close?

10. Security: xterm SUID root !!!

11. Security problem from dip and route being SUID root?

12. Security holes in VGA setuid-root utils

13. Solaris 2.5 Security Hole: local users can get root