full-disclosure - Re: DLL hijacking on Linux

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Wed, 25 Aug 2010 14:00:37 -0400
From: Paul Davis <paul.joseph.davis@...il.com>
To: security@...chdb.apache.org
Cc: security@...ian.org, full-disclosure@...ts.grok.org.uk,
	security <security@...ntu.com>
Subject: Re: DLL hijacking on Linux

Dan.

I concur, it does look to be introduced in the Ubuntu packaging to use
the xulrunner version of Spidermonkey. If there's anything you need
upstream to make this easier to fix, let us know.

Paul

On Wed, Aug 25, 2010 at 1:55 PM, Dan Rosenberg
<dan.j.rosenberg@...il.com> 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@...il.com> 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@...35.com> 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@...35.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/
>>>
>>
>

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