Date: Tue, 28 Oct 1997 02:47:17 -0800 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: Terry Lambert <tlambert@primenet.com>, Don.Lewis@tsc.tdk.com (Don Lewis) Cc: jamil@trojanhorse.ml.org, thorpej@nas.nasa.gov, joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@FreeBSD.ORG Subject: Re: Possible SERIOUS bug in open()? (Big time bug) Message-ID: <199710281047.CAA25242@salsa.gv.tsc.tdk.com> In-Reply-To: Terry Lambert <tlambert@primenet.com> "Re: Possible SERIOUS bug in open()? (Big time bug)" (Oct 28, 4:08am)
next in thread | previous in thread | raw e-mail | index | archive | help
On Oct 28, 4:08am, Terry Lambert wrote: } Subject: Re: Possible SERIOUS bug in open()? (Big time bug) } > I don't think administrators who remove "r" access to keep users } > from copying executables would like this, since the users could } > just switch to a copying program that uses mmap. } } A user can just ctrl-\ the thing and get a core and "undump" it now. At least in FreeBSD that doesn't seem to get them a copy of the text segment which would seem to diminish the usefulness of the core file. } If it's a net program, they can just download it. Yes, but I was thinking more of commercial-ware with license restrictions on copying. } > I think it would be better to add a kernel hook so that the emulator } > could be registered as an interpreter for foreign binaries. The } > kernel could then open an fd and pass it to the emulator when the } > binary is execed. Something similar would allow you to remove the } > "r" permissions from shell scripts. } } This route leads to chaos. Consider a foreign binary which is suid; } you would end up with the same issues that you would get if SUID shell } scripts worked (in effect, an emulator that worked this way would be } a "different kind of shell interpreter with the foreigh binary instead } of '#!' as the 'magic number'" -- this would be bad). The biggest problem with suid scripts is the race condition between the kernel check to see if the script is suid and the interpreter opening the script, which gives a cracker the opportunity to change the symlink to point to some evil but not suid script that he wishes to execute with inappropriate privileges. This race condition is eliminated if the kernel opens the script file and points the interpreter at /dev/fd/whatever instead of the script file (or you can use the strategy of suidperl). Of course you should give the administrator a knob to completely disable suid scripts and foreign binaries.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710281047.CAA25242>