Re: [Full-disclosure] DLL hijacking on Linux

[Noah Slater <nslater@xxxxxxxxxx>]

Just doesn't affect the official releases?



On 25 Aug 2010, at 18:55, Dan Rosenberg <dan.j.rosenberg@xxxxxxxxx> wrote:

> ...And it looks like I jumped the gun on blaming upstream.  The
> vulnerability was introduced by Debian patch
> "mozjs1.9_ldlibpath.patch" on 3/24/2009.
> 
> -Dan
> 
> On Wed, Aug 25, 2010 at 1:23 PM, Dan Rosenberg
> <dan.j.rosenberg@xxxxxxxxx> wrote:
>> Apache CouchDB (tested on Ubuntu 10.04) is vulnerable to exactly this
>> issue.  The script installed on my machine at /usr/bin/couchdb first
>> sets LD_LIBRARY_PATH with:
>> 
>> LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/xulrunner-`xulrunner-1.9.2
>> --gre-version`/
>> 
>> At the time of invocation, the following environment is set up:
>> 
>> command="env \"LD_LIBRARY_PATH=/usr/lib:${LD_LIBRARY_PATH}\" \
>> ...
>> 
>> So in the normal case where LD_LIBRARY_PATH is empty at the time of
>> invocation, the resulting path will be:
>> 
>> /usr/lib::/usr/lib/xulrunner-[version]/
>> 
>> The vulnerability to hijacking can be trivially verified by creating a
>> fake libc.so.6 in your current directory and running /usr/bin/couchdb.
>>  Fortunately, the init script changes directories before executing
>> couchdb, so exploitation is limited to cases where /usr/bin/couchdb is
>> invoked directly inside a hostile current directory.  Not a likely
>> exploitation scenario, but it still should probably be fixed.
>> 
>> -Dan
>> 
>> On Wed, Aug 25, 2010 at 5:58 AM, Tim Brown <tmb@xxxxxxxxx> wrote:
>>> On Wednesday 25 August 2010 10:38:37 Mihai Donțu wrote:
>>> 
>>>> man sudo(8):
>>>> "Note that the dynamic linker on most operating systems will remove
>>>> variables that can control dynamic linking from the environment of setuid
>>>> executables, including sudo. Depending on the operating system this may
>>>> include _RLD*, DYLD_*, LD_*, LDR_*, LIBPATH, SHLIB_PATH, and others. These
>>>> type of variables are removed from the environment before sudo even begins
>>>> execution and, as such, it is not possible for sudo to preserve them."
>>> 
>>> Absolutely, but in the case I gave, the path is set /by the script/, not
>>> inherited from the original user.  The script sets the dangerous path, but
>>> since sudo hasn't changed the CWD it points at the directory the user 
>>> running
>>> sudo was in.
>>> 
>>> Tim
>>> --
>>> Tim Brown
>>> <mailto:tmb@xxxxxxxxx>
>>> 
>>> _______________________________________________
>>> Full-Disclosure - We believe in it.
>>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>>> Hosted and sponsored by Secunia - http://secunia.com/
>>> 
>> 

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/