[9093] in bugtraq
Re: Can you really trust a path?
daemon@ATHENA.MIT.EDU (route@RESENTMENT.INFONEXUS.COM)
Sun Jan 17 23:37:16 1999
Date: Sat, 16 Jan 1999 12:47:20 -0800
Reply-To: route@RESENTMENT.INFONEXUS.COM
From: route@RESENTMENT.INFONEXUS.COM
X-To: md@LINUX.IT
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <19990115221231.B4362@wonderland.linux.it> from "Marco d'Itri" at
Jan 15, 99 10:12:31 pm
[Marco d'Itri wrote]
|
| AFAIK no one suggested yet that trusted path implementations like the
| ones in recent Phrack issues can be trivially broken with perl XS
| modules. A step by step guide to convert your favourite exploits can be
| found in perlxstut(1p).
Interpreters of any kind can be used to break TPE. The article in question
(http://www.rrdl.net/daemon9/Projects/Phrack/P54-06) discusses this to a
certain extent.
| 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.
This is also mentioned in the article, and the suite provides a workaround,
"ld.so environment protection".
The fact of the matter is that there are numerous ways to break trusted
path execution. The major reason for this is that it is a retrofit to
an existing infrastructure. TPE is not a panacea by any means, however, it
does afford the admin protection from typical localhost attacks (especially
from cut and paste attackers). It also, to a certain extent, keeps users
from hacking from your machine.
--
I live a world of paradox... My willingness to destroy is your chance for
improvement, my hate is your faith -- my failure is your victory, a victory
that won't last.
