[3221] in bugtraq
Re: libresolv+ bug
daemon@ATHENA.MIT.EDU (der Mouse)
Tue Aug 20 02:21:09 1996
Date: Mon, 19 Aug 1996 19:34:55 -0400
Reply-To: Bugtraq List <BUGTRAQ@NETSPACE.ORG>
From: der Mouse <mouse@Holo.Rodents.Montreal.QC.CA>
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@NETSPACE.ORG>
>> It just switches the effective uid to nobody (default 65534) around
>> a certain gethostbyname ...
>> This fixed the problem as far as I can tell on my system...
> This is not a fix for any of the libresolv++ holes.
Well, it makes them slightly harder to exploit. :-)
> Firstly you can use the TRIM list to overrun the trim buffer non
> setuid, but make the non setuid code executed patch other parts of
> the binary so that when it goes back setuid -- BLAM.
Well, if the text segment is read-only, that makes it rather difficult
to patch the binary. But if the binary has privilege to go setuid,
then it has that privilege even when executing the buffer-overrun code,
so (as you say, but for slightly different reasons) it buys you nothing
in terms of real security.
It would perhaps be something to consider for hardware designers to
ensure that any useful sequence of code will contain a 0x00 byte; it
would make a lot of such overruns harder to exploit, since most of
these overruns do not permit installing any code that contains a 0x00
byte. (Which is one reason they're so bad on Intel hardware, it being
a CISC architecture - I once saw a file which was simultaneously code
in about three high-level languages and an Intel machine-language
executable (!), which means that someone wrote a useful program that
used only bytes that were printable characters....)
der Mouse
mouse@collatz.mcrcim.mcgill.edu
01 EE 31 F6 BB 0C 34 36 00 F3 7C 5A C1 A0 67 1D
