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

[JYoungman () VGGAS COM (James Youngman)]

> > > > > "jz" == Joe Zbiciak <j-zbiciak1 () ti com> writes:

  jz> Alan Cox actually is the first person who highlighted this sort
  jz> of vulnerability to me.  Does anyone know if the OpenBSD

I initially mentioned this problem on the Linux security-audit mailing
list, of which Alan is a (very active!) member.

I did this based on having discovered this to be a problem in an SCCS
clone I was writing (you clould get stderr output to end up in the
SCCS file :-).  The thought isn't originally mine.  I have a _small_
stack of documentation on secure programming around the place and this
particular item comes from a manpage entitled simply SETUID(7), which
I got off the web (its header indicates that it was generated by a CGI
script).

  jz> approach is sufficient for avoiding these sorts of attacks
  jz> (eg. feeding an suid/sgid program bogus stdin/stdout/stderr)?
  jz> Also, is a similar patch in the works for Linux?  (I ask,

I'm not sure.  Though the specification about which fd-related aspects
of the parent are inherited isn't worded in such a way that it's easy
to tell, it looks like the X/Open or POSIX specs may rule out this
global fix (from memory the spec says that open fds are inherited,
which leaves the question of _closed_ fds a little unaddressed).  The
specs for open(), fopen() and dup() all indicate that they will return
the first free file descriptor.

  jz> because I'm a Linux user myself.)  And, is there any
  jz> overwhelming reason why you wouldn't make the same guarantee
  jz> that fd's 0..2 are open for all processes, rather than just
  jz> suid/sgid processes?

One might say that /bin/sh would not provide "<&-" if it were not
actually used.  So I guess *some* programs use it.

  jz> On an alternate note, what are the security implications of
  jz> opening "/dev/null" exactly by name?

It won't work in some chroot()ed environments -- where there is not
always a /dev/null visible at all.