Full Disclosure mailing list archives
Re: DLL hijacking on Linux
From: Noah Slater <nslater () apache org>
Date: Wed, 25 Aug 2010 19:02:44 +0100
Just doesn't affect the official releases? On 25 Aug 2010, at 18:55, Dan Rosenberg <dan.j.rosenberg () gmail 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 () gmail 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 () 65535 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 () 65535 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/
Current thread:
- DLL hijacking on Linux Tim Brown (Aug 25)
- Re: DLL hijacking on Linux Mihai Donțu (Aug 25)
- Re: DLL hijacking on Linux Tim Brown (Aug 25)
- Re: DLL hijacking on Linux Dan Rosenberg (Aug 25)
- Re: DLL hijacking on Linux Dan Rosenberg (Aug 25)
- Re: DLL hijacking on Linux bk (Aug 25)
- Re: DLL hijacking on Linux paul . szabo (Aug 25)
- Re: DLL hijacking on Linux Noah Slater (Aug 26)
- Re: DLL hijacking on Linux Paul Davis (Aug 26)
- Re: DLL hijacking on Linux Tim Brown (Aug 25)
- Re: DLL hijacking on Linux Noah Slater (Aug 26)
- Re: DLL hijacking on Linux Mihai Donțu (Aug 25)