[9142] in bugtraq
Re: Can you really trust a path?
daemon@ATHENA.MIT.EDU (Marco d'Itri)
Thu Jan 21 12:31:05 1999
Date: Wed, 20 Jan 1999 12:33:47 +0100
Reply-To: "Marco d'Itri" <md@LINUX.IT>
From: "Marco d'Itri" <md@LINUX.IT>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <Pine.GSO.3.96.990119231919.8982A-100000@pubnix.org>; from jtb on
Tue, Jan 19, 1999 at 11:21:30PM -0500
On Jan 20, jtb <jtb@pubnix.org> wrote:
>> Another way to execute your code in a trusted path environment is
>> exploiting the ability of some programs (e.g. BitchX) to link shared
>> objects at run time from a predefined set or even user-supplied ones.
>> libdl looks at $LD_LIBRARY_PATH too, so the user can supply his own
>> directory with a shared object containing arbitrary code.
>I'm not sure if you bothered to _read_ the documentation that went along
>with the Phrack articles, because if you had you would have realized that
I'm not sure if you and daemon9 bothered to read my message.
You are right, the second vulnerability I describe does not fully works
because ld.so removes the variables from the environment so libdl can't
find them, but it's still possible to ask some programs to dinamically
link random shared objects.
This "protection" looks like more of a side effect of the ld.so
protection than something to deal with libdl attacks.
libdl is not not mentioned anywhere in the article AFAICS.
e.g. bitchx will happily load any file with libdl:
/loaddll /dev/null
-:- BitchX+Deb1an: couldn't load file: <garbage>: cannot map file data:
Operation not supported by device
open("/dev/null", O_RDONLY) = 4
mmap(0, 4096, PROT_READ, MAP_PRIVATE, 4, 0) = -1 ENODEV (Operation not supported by device)
close(4) = 0
I'm not attacking anybody, just expressing my point: I believe there are
too many ways to bypass TPE schemes to consider them a real barrier
against malicious people.
--
ciao,
Marco
