Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
Re: FD's 0..2 and suid/sgid procs (Was: Crash a redhat 5.1 linuxRoger Espel Llima (espelIAGORA.COM)
Thu, 30 Jul 1998 13:30:28 -0400
- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: James Youngman: "Re: Possible root exploit in Linux povray"
- Previous message: Adam Monaghan: "Re: Object tag crashes Internet Explorer 4.0"
- In reply to: Joe Zbiciak: "FD's 0..2 and suid/sgid procs (Was: Crash a redhat 5.1 linux box)"
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, 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, espelllaic.u-clermont1.fr -o) http://www.eleves.ens.fr:8080/home/espel/index.html /\\ _\_v