|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
Date: Thu, 30 Jul 1998 18:25:12 +0100 Reply-To: James Youngman <JYoungman@VGGAS.COM> From: James Youngman <JYoungman@VGGAS.COM> X-To: j-zbiciak1@ti.com To: BUGTRAQ@NETSPACE.ORG In-Reply-To: Joe Zbiciak's message of Wed, 29 Jul 1998 19:02:33 -0500 >>>>> "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.
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |