Bugtraq mailing list archives
Re: FD's 0..2 and suid/sgid procs (Was: Crash a redhat 5.1 linux
From: espel () IAGORA COM (Roger Espel Llima)
Date: Thu, 30 Jul 1998 13:30:28 -0400
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
Current thread:
- Re: Fwd: Any user can panic OpenBSD machine, (continued)
- Re: Fwd: Any user can panic OpenBSD machine Warner Losh (Jul 27)
- Re: Fwd: Any user can panic OpenBSD machine J.R. Valverde (Jul 28)
- Re: Fwd: Any user can panic OpenBSD machine Felix Schroeter (Jul 28)
- netscape mail overflow(another one) Paul Boehm (Jul 28)
- Re: netscape mail overflow(another one) Brett Glass (Jul 28)
- Re: netscape mail overflow(another one) pedward () WEBCOM COM (Jul 29)
- HP-UX Predictive & Netscape SSL Vulnerabilities Aleph One (Jul 29)
- Long attachment filename exploits: a procmail filter John D. Hardin (Jul 29)
- Crash a redhat 5.1 linux box Zachary Amsden (Jul 29)
- FD's 0..2 and suid/sgid procs (Was: Crash a redhat 5.1 linux box) Joe Zbiciak (Jul 29)
- Re: FD's 0..2 and suid/sgid procs (Was: Crash a redhat 5.1 linux Roger Espel Llima (Jul 30)
- Re: FD's 0..2 and suid/sgid procs (Was: Crash a redhat 5.1 linux Alan Cox (Jul 30)
- Re: FD's 0..2 and suid/sgid procs (Was: Crash a redhat 5.1 linux Pavel Kankovsky (Jul 30)
- Re: netscape mail overflow(another one) Paul Boehm (Jul 29)
- who Paul Boehm (Jul 28)
- Re: Fwd: Any user can panic OpenBSD machine Chris Wedgwood (Jul 28)
- Re: Fwd: Any user can panic OpenBSD machine Todd C. Miller (Jul 27)