>>>>> "jz" == Joe Zbiciak <j-zbiciak1at_private> 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.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:11:02 PDT