Re: FD's 0..2 and suid/sgid procs (Was: Crash a redhat 5.1 linux

From: Roger Espel Llima (espelat_private)
Date: Thu Jul 30 1998 - 10:30:28 PDT

  • Next message: Piotr Strzyżewski: "Security Bulletins Digest (fwd)"

    On Wed, Jul 29, 1998 at 07:02:33PM -0500, Joe Zbiciak wrote:
    > It's worth noting that the fdalloc patch for OpenBSD that Theo de Raadt
    > briefly mentioned addresses this issue by forcing suid/sgid programs to
    > have open files (specifically /dev/null) on fd's 0..2 so that things
    > like printf() and fprintf(stderr,...) don't cause the sort of problem
    > you're highlighting.  (see http://www.openbsd.org/security.html and
    > click on "Jul 2, 1998: setuid and setgid processes should not be
    > executed with fd slots 0, 1, or 2 free. (patch included).")
    
    This is certainly the easy solution, but I'd contend that it's wrong
    to force fd's 0..2 to be open in any case.  It's really the privileged
    program's responsibility to check the environment it was passed at
    startup.  Unix semantics say that you _can_ exec() a program with fd's
    0..2 closed, with ignored signals, with a pending alarm, with no argv[0],
    with ridiculous resource limits, a non-existing current directory, etc.
    And we've seen exploits here and there that used these features...
    
    So I think the right approach is to make library function that checks
    the environment for sanity and restores some defaults (maybe taking
    some parameters, about whether to touch signals or not, to touch alarms
    or not, etc), and call it at the beginning of privileged programs.
    
    > On an alternate note, what are the security implications of opening
    > "/dev/null" exactly by name?  (I can't profess to be an expert in
    > reading OpenBSD kernel source-code, but that appears to be what the
    > patch does for fd's 0..2 that aren't yet open.)  Pertinent bit of the
    > patch:
    
    The only implications I can think of is that /dev could not exist or not
    be mounted, or /dev/null could not exist or not be of the right type,
    in which case weird things would happen.  But only root can change
    what "/dev/null" refers to, so it doesn't really look like a security
    implication.
    
    For the record, I've seen a system once where /dev/null was a plain file,
    mode 666.  I have no idea why it was that way, but the system appeared
    to be working OK, apart from the fact that all kinds of discarded,
    potentially sensitive stuff was accumulating there.
    
    --
    Roger Espel Llima, espelat_private-clermont1.fr                     -o)
    http://www.eleves.ens.fr:8080/home/espel/index.html               /\\
                                                                     _\_v
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:11:07 PDT