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 for Android: free password hash cracker in your pocket

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

Message-Id: <1CDC7FF1-E437-4360-88FE-35DEB7A3FEF5@apache.org>
Date: Wed, 25 Aug 2010 18:57:02 +0100
From: Noah Slater <nslater@...che.org>
To: "security@...chdb.apache.org" <security@...chdb.apache.org>
Cc: "full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>,
	"security@...chdb.apache.org" <security@...chdb.apache.org>
Subject: Re: DLL hijacking on Linux

I would fix this but am on holiday. If someone wants to post a suggested patch to this thread, I am happy to review.



On 25 Aug 2010, at 18:23, 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/