[7508] in bugtraq
Re: FD's 0..2 and suid/sgid procs (Was: Crash a redhat 5.1 linux
daemon@ATHENA.MIT.EDU (Roger Espel Llima)
Thu Jul 30 18:33:09 1998
Mail-Followup-To: j-zbiciak1@ti.com, BUGTRAQ@netspace.org
Date: Thu, 30 Jul 1998 13:30:28 -0400
Reply-To: Roger Espel Llima <espel@IAGORA.COM>
From: Roger Espel Llima <espel@IAGORA.COM>
X-To: j-zbiciak1@ti.com
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <199807300002.TAA13131@asterix>; from Joe Zbiciak on Wed, Jul 29,
1998 at 07:02:33PM -0500
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, espel@llaic.u-clermont1.fr -o)
http://www.eleves.ens.fr:8080/home/espel/index.html /\\
_\_v
