Writing a safe suid root program

Writing a safe suid root program

Post by Thomas Koen » Tue, 05 Oct 1993 01:07:53



What are the things one has to take care of when writing a suid root
program?

I've found a few points, and I'm wondering if other people could
add some more.

- Don't use buffers which could be overrun by the user; use dynamic
  memory or truncuate his input, if necessary.  Using gets() or
  scanf("%s") is a sure way to ruin.

- Don't use functions which rely on the user's environment.  Invoking
  another program via system(), popen() or exec?p without explicitly
  setting your own environment including PATH and IFS is a no-no,
  as is using the tmpnam() function, which rely on the user's
  TMPDIR.

- Don't write to files if the user has write permission in any
  of the directories leading up to it, if you need to open the
  file to write to it.  Writing to stdout and stderr should
  be ok (IS THAT RIGHT?), as should be reading from stdin.

- Don't trust filenames supplied by the user for either reading or
  writing.  Using access() is not enough, because of possible race
  conditions and symbolic links.  (The only solution I've found so far
  is to fork off a child, which does a setgid(getgid());
  setuid(getuid());, then opens the file and reads from/ writes to it,
  communicating with its parent with a pipe.  This is far from elegant,
  though).

- Check for every failed function call, and abort if necessary.

Anything more?
--

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

 
 
 

Writing a safe suid root program

Post by Thomas Dwyer I » Wed, 06 Oct 1993 12:34:36



>What are the things one has to take care of when writing a suid root
>program?

>I've found a few points, and I'm wondering if other people could
>add some more.

>[list deleted]

Under SunOS (and probably others) make sure you link libraries static
rather than dynamic.  Otherwise a user pointing LD_LIBRARY_PATH at
a hacked library will have easy access to your system.

Tom.III

----------------------------------------------------------------

Systems Programmer                      Voice:   (906) 487-2112
Computing Technology Services           Fax:     (906) 487-2787
Michigan Technological University       VHF/UHF: N8MHF

 
 
 

Writing a safe suid root program

Post by Anna Pluzhnik » Wed, 06 Oct 1993 12:52:49




>>What are the things one has to take care of when writing a suid root
>>program?

>>I've found a few points, and I'm wondering if other people could
>>add some more.

>>[list deleted]

>Under SunOS (and probably others) make sure you link libraries static
>rather than dynamic.  Otherwise a user pointing LD_LIBRARY_PATH at
>a hacked library will have easy access to your system.

$ uname -a
SunOS kimbark 4.1.3 1 sun4m
$ man ld.so
...
ENVIRONMENT
     LD_LIBRARY_PATH
...
          NOTE:  when  running  a  set-user-  or
          set-group-ID   program,  ld.so  will  only  search  for
          libraries  in  directories  it  "trusts",   which   are
          /usr/lib,  /usr/5lib,  /usr/local/lib,  and  any direc-
          tories specified within the executable as a  result  of
          -L options given when the executable was constructed.
 
 
 

Writing a safe suid root program

Post by Matthew Hannig » Thu, 07 Oct 1993 10:50:37




>>Under SunOS (and probably others) make sure you link libraries static
>>rather than dynamic.  Otherwise a user pointing LD_LIBRARY_PATH at
>>a hacked library will have easy access to your system.

>$ uname -a
>SunOS kimbark 4.1.3 1 sun4m
>$ man ld.so
>...
>ENVIRONMENT
>     LD_LIBRARY_PATH
>...
>          NOTE:  when  running  a  set-user-  or
>          set-group-ID   program,  ld.so  will  only  search  for
>          libraries  in  directories  it  "trusts",   which   are
>          /usr/lib,  /usr/5lib,  /usr/local/lib,  and  any direc-
>          tories specified within the executable as a  result  of
>          -L options given when the executable was constructed.

Well replied :-).

Question: Is it possible to increase this set of "trusted" directories.
I couldn't figure out a way, to my annoyance.  Running ldconfig as
root was not helpful.  I had to copy the libraries on a 3rd party
product to the trusted dirs.   I'd rather do it the first way.

--
        -Matt

 
 
 

Writing a safe suid root program

Post by Casper H.S. D » Thu, 07 Oct 1993 17:53:20



Quote:>Under SunOS (and probably others) make sure you link libraries static
>rather than dynamic.  Otherwise a user pointing LD_LIBRARY_PATH at
>a hacked library will have easy access to your system.

There has been no version of SunOS where set-uid executables could be
so easily subverted as you make us believe here.

The runtime linker has always only used libraries in ``trusted'' directories
when an executable is set-uid/set-gid.

There have been two problems with set-uidness and shared libraries:

        - set-uid programs that run children under another uid
          (with euid=uid). E.g., sendmail, su, login.
          (This problem exists in SunOS 4.x/5.x and there is no easy fix.
          The work around is the have the affected set-uid executables
          remove LD_* variables from the environment. In 5.x this is standard,
          for 4.1.x there is a patch. By no means all set-uid executables
          are effected)

        - trusted relative paths in executables.
          This problem was introduced in 4.1.0 and not fixed until
          4.1.2 (and the 4.1.1 ld/ld.so jumbo patch).
          One notable victim of this was xterm because of the use of
          -L../../lib/X -lX11 and the like during the R5 build.

The trusted path can be extended for a specific executable when linking
with:

    SunOS 4.1.x: -L <dir1> -L <dir2> ...
    SunOS 5.0,5.1,5.2: LD_RUN_PATH or -R <dir1>:<dir2>... (only one -R option)
    SunOS 5.3 and later: LD_RUN_PATH or -R <dir1> -R <dir2> ...

(Not 100% sure about Solaris 2.3 and later)

Casper

 
 
 

Writing a safe suid root program

Post by Thomas Dwyer I » Fri, 08 Oct 1993 13:15:19




>>Under SunOS (and probably others) make sure you link libraries static
>>rather than dynamic.  Otherwise a user pointing LD_LIBRARY_PATH at
>>a hacked library will have easy access to your system.

>There has been no version of SunOS where set-uid executables could be
>so easily subverted as you make us believe here.

Yep.  I was confused.  I was thinking about a completely different
problem I had a while back involving the LD_PRELOAD variable.

Tom.III

 
 
 

Writing a safe suid root program

Post by Barry Margol » Sun, 10 Oct 1993 03:17:30



>Question: Is it possible to increase this set of "trusted" directories.
>I couldn't figure out a way, to my annoyance.  Running ldconfig as
>root was not helpful.  I had to copy the libraries on a 3rd party
>product to the trusted dirs.   I'd rather do it the first way.

Unfortunately, the libraries that setuid programs trust are hard-coded into
ld.so.

ldconfig merely updates a cache, to speed up dynamic linking.  It would be
wrong for the setuid check to make use of this in its "trusted" directory
determination.  If you have a commonly used library you might run ldconfig
over it, even if it isn't trusted for setuid programs, since you would
still want linking to it to be fast.
--
Barry Margolin
System Manager, Thinking Machines Corp.


 
 
 

Writing a safe suid root program

Post by Casper H.S. D » Sun, 10 Oct 1993 21:22:33




}>Question: Is it possible to increase this set of "trusted" directories.
}>I couldn't figure out a way, to my annoyance.  Running ldconfig as
}>root was not helpful.  I had to copy the libraries on a 3rd party
}>product to the trusted dirs.   I'd rather do it the first way.
}Unfortunately, the libraries that setuid programs trust are hard-coded into
}ld.so.

You can add to this list with -L<directory> at link time.
(Directories should start with /, some versions of SunOS
except relative pathnames, that's a security hole)

Casper

 
 
 

1. Writing safe suid programs

Howdy!

Ok, I'm investigating something I'm not quite sure about and it concerns
the use of either setreuid or seteuid to change between user id's.

Here's the thing: what I'd like to do is have a program which is suid to root.
Now as soon as you enter into this program, I want it to change the effective
ID back to the calling process, since it does stuff (like creating sub-shells)
that I DON'T want it to be root as.

Anyway, after I while, I want it to open a file which is only read/writeable
by root. At this point I'd like to reset the effective user ID back to root,
open the file, do my stuff, close it, and reset euid back to real-uid.

Kinda like this:
--------------------
#include <stdio.h>
#include <sys/types.h>
main() {
        uid_t saved_uid;
        saved_uid = geteuid();
        setreuid(-1,getuid());
/* normal dude */
        .
        .
        .
/* now go back to root */
        setreuid(-1,saved_uid);
        .
        .
        .
/* now back again to real uid */
        setreuid(-1,getuid());
        .
        .
        .
--------------------

Anyway, as it's "implemented" above, the 2nd setreuid ("back" to root)
fails, since, at this point, the process no longer has an effective root
uid. But I seem to recall a long time ago that the set-user uid was saved
somewhere to allow this to happen. In fact, I even have a few books that
mention this "technique" in writting correct suid scripts... so what's the
rub...

Or is this not even possible??
--
==============================================================================
#include <std/disclaimer.h>

           Jim Jagielski                    NASA/GSFC, Code 711.4

  "...there is no cannibalism in the British Navy. Absolutely none. And
   when I say none, I mean there is a certain amount..."

2. detecting media insertion

3. Writing suid root program

4. CD-ROM audio problem

5. Is procmail safe to suid root?

6. Some help witth C.

7. Safe pseudo-suid execution of user programs

8. Problem with "databases" in ports collection

9. clearing SUID and SGID bits on non-root write

10. FS for root: slow write, fast read, and safe on corruption?

11. IS there a way to trace suid program with suid permissions

12. Are there any guidelines for writing a secure SUID program?

13. SUID root programs