Date: Tue, 24 Oct 1995 07:45:13 +0300 (MSK) From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) <ache@astral.msk.su> To: Nate Williams <nate@rocky.sri.MT.net> Cc: ache@freefall.freebsd.org, freebsd-hackers@freebsd.org Subject: Re: ld.so, LD_NOSTD_PATH, and suid/sgid programs Message-ID: <OaPz6ZmC14@ache.dialup.demos.ru> In-Reply-To: <199510240419.WAA24802@rocky.sri.MT.net>; from Nate Williams at Mon, 23 Oct 1995 22:19:14 -0600 References: <m0t7SFB-000078C@seattle.polstra.com> <Aagc1ZmOzJ@ache.dialup.demos.ru> <199510232318.RAA24039@rocky.sri.MT.net> <Faij2Zmq8S@ache.dialup.demos.ru> <199510240010.SAA24195@rocky.sri.MT.net> <Cax53Zm0GT@ache.dialup.demos.ru> <199510240233.UAA24556@rocky.sri.MT.net> <PaYN5Zm4G1@ache.dialup.demos.ru> <199510240419.WAA24802@rocky.sri.MT.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199510240419.WAA24802@rocky.sri.MT.net> Nate Williams
writes:
>> >Well, simple example:
>>
>> > setuid_shared_binary > /tmp/file
>> > ... (f.e. few static commands)
>> > setuid_static_binary < /tmp/file # OOPS!
>> > (umask is restrictive, of course)
>How will this example fail if you set LD_NOSTD_PATH?
It produce empty /tmp/file instead of valid data (first
binary drops core at startup).
Safely LD_NOSTD_PATH itself is not fully implemented in FreeBSD.
>> When LD_NOSTD_PATH is set (when it will works, of course),
>> first binary fails leaving an empty file and second binary
>> got empty input when it isn't suppose it.
>And the problem is?
Second binary can treat empty data in unpredictable way.
>> I assume script was unbreakable, of course, i.e. all signals
>> was disabled. Now it becomes breakable.
>Why is the script breakable?
I mean that script/program writers allow user only _run_
programs, not stop or fail them.
>> Basically it means that intruder gains ability to selectively
>> control execution flow.
>Sigh, I think there are much bigger holes in the system that folks will
>have problems with if you attempt to use 'secure' shell scripts.
I agree. But disabling even some holes reduces probability of secure
violation.
As I already mention, it isn't stuck on "shell scripts" only, entering
the same command by hand give the same results.
Imagine some database manipulations/requests handling with
requestor programs started by hand.
--
Andrey A. Chernov : And I rest so composedly, /Now, in my bed,
ache@astral.msk.su : That any beholder /Might fancy me dead -
http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead.
RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?OaPz6ZmC14>