Some Linux Distros Vulnerable to Version of DLL Hijacking Bug

In the wake of all of the stories about the Windows DLL hijacking bug, it appears that certain Linux distributions may be vulnerable to a similar problem related to the way that Linux handles a specific variable in some cases. The bug apparently was introduced via a Debian patch last year.

In the wake of all of the stories about the Windows DLL hijacking bug, it appears that certain Linux distributions may be vulnerable to a similar problem related to the way that Linux handles a specific variable in some cases. The bug apparently was introduced via a Debian patch last year.

The discussion on the possible bug in Linux began with a blog post by Tim Brown, a UK-based security researcher, who detailed a specific case in which Linux could be vulnerable to an attack similar to those designed to exploit the Windows DLL bug. The post spawned a related discussion on the Full-Disclosure mailing list, in which several others confirmed that they’d seen the problematic behavior in certain Linux distributions, including Fedora, Ubuntu and Debian.

In an interview, Brown said that the bug most likely will be found in closed-source systems that have been compiled against some third-party libraries and that the bug would be difficult to exploit remotely.

“There might be some corner cases where it’s exploitable remotely, but there’s nothing equivalent to UNC in Linux. But this is something that most of the major distributions might want to consider patching,” Brown said. “Everything is a concern until proven otherwise, but it really depends on what packages someone has installed. It’s something that any half-competent Linux coder should be able to cook up an exploit for.”

Brown said that the bug looks to have been introduced through a Debian patch in March 2009.

In his post, Brown describes how Linux could be vulnerable to a similar DLL-hijacking bug:

The Linux dynamic linker makes use of a variable called LD_LIBRARY_PATH which it consults when a binary is executed and which takes precedence over the OS default as set in ld.so.conf. So where’s the problem? Consider the following script:

#!/bin/sh
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path/to/app/lib
app start

What happens if LD_LIBRARY_PATH isn’t set? Well, in that case, the app binary path is executed with an LD_LIBRARY_PATH of :/path/to/app/lib.
This may seem perfectly satisfactory, but here’s the rub. When the
Linux dynamic linker sees a path with an empty directory specification
such as :/valid/path, /valid/path: or /valid::/path, it treats the empty specification as $PWD. This could lead to a library being loaded from the users current working directory but where might it be exploitable.

In the discussion on Full-Disclosure, one user said he’d been able to reproduce this on the Apache CouchDB database running on Ubuntu 10.04. Tomas Hoger, a member of the Fedora Security Response Team, said on the OSS Security mainling list Thursday that Fedora is in fact vulnerable to this bug.

“This patch does not seem to be included in current Debian stable 0.8.0-2 and testing/unstable 0.11.0-2+b1 packages, but can be found in Ubuntu versions. Stable Debian contains cu-config.patch instead which seems to introduce the very same problem and is also used in some Fedora packages,” Hoger wrote.

It’s unclear at this point whether there’s an easy fix for the problem.

However, security experts say the problem isn’t on the same scale as the DLL hijacking flaw and is far less worrisome. Dave Aitel, CTO of Immunity, said that the Linux problem doesn’t appear to be a direct analog to the Windows DLL bug, which he characterized as a serious flaw in the operating system, much like the Windows shatter attacks from 2002.

“I’d have to say that those are two completely different things. The Windows bug is an architectural flaw, similar to the shatter flaw years ago in the sense that it is something that cannot realistically be fixed, and is horribly broken. Another architectural flaw was allowing WebDav UNC shares in the first place,” Aitel said. “No platform is perfect, but in this area, Windows is the least perfect of the two.”

Suggested articles

Discussion

  • RichieB on

    First of all, sudo will by default not pass the LD_LIBRARY_PATH to the commands it executes. (As assumed in the blog post.)

    In order to compare this behavior of ld.so (which I think should be fixed) to the Windows DLL search path issue, you need:

    1. A handler that executes a command when opening a certain type of document
    2. That command needs to be a script using LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path/to/app/lib
    3. LD_LIBRARY_PATH need to be initially empty
    4. The CWD needs to be in a place where an attacker can place a malicious shared object (.so)


    Even if 1+2 exists by default on a Linux system, 4 will not. Linux does not allow you to on-the-fly open a share/web folder/mount point just because you visit a webpage or click on a link in an E-mail. Windows does. That's why the DLL search path issue is a big threat, and this behavior of ld.so isn't.

  • Tim Brown on

    I totally agree with what both Richie and Dave have said with regard to the liklihood of exploitation being that much lower with the issue I described.  It's actually the WebDAV element that makes the Windows issue interesting. Having said that, developers can and do make mistakes, as the CouchDB vulnerability shows.

    The point of the original post was to respond to some of the misconceptions people have about how the Linux linker operates.  It's a tool and like many tools it can cause injury if not used correctly.  The /. mentatility often appears to be Linux good, Windows bad but the reality isn't that simple.  Why did I choose the example I chose (there are other fun gotchas with the Linux linker), well because I know there are scripts that are out there that are vulnerable from my work auditing UNIX hosts for clients.

    For the record, my post doesn't assume that LD_LIBRARY_PATH will be passed by sudo.  As I explained in a follow up posting on f-d, my post relies upon the fact that the script which sudo executes sets LD_LIBRARY_PATH insecurely.  The problem is that sudo doesn't change the users directory when changing privilege which means that if LD_LIBRARY_PATH is set insecurely that it could end up pointing at a CWD which the calling user has writable access.

    A final couple of points, it's not clear who originally introduced the patch that lead to CouchDB being vulnerable and "closed-source systems that have been compiled against some open-source libraries" should really read "closed-source systems that have been compiled against 3rd party libraries". The common cases where I have seen this being exploitable is where closed source software is installed under application specific directories under /opt and /home and need to reference their own copies of libraries rather than rely on the OS packaged versions.

  • RichieB on

    Thanks Tom for clarifying. I agree that if a script uses LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path/to/app/lib and it can be used via sudo, this is a serious issue leading to privilege escalation.

    Do you know if this ld.so behavior of treating an empty entry in LD_LIBRARY_PATH as CWD is going to be addressed? Is it being accepted as a security issue by the Linux developers?

  • FrickelHack on

    Quick fix: locate .sh | xargs grep -lF 'LD_LIBRARY_PATH=$LD_LIBRARY_PATH:' | sed -i 's#(LD_LIBRARY_PATH=)[$]LD_LIBRARY_PATH:([^[:space:]]+)#1=2${LD_LIBRARY_PATH+":$LD_LIBRARY_PATH"}#' Note: this will only catch non-quoted occurences in scripts actually named *.sh
  • Anonymous on

    Linux does not allow you to on-the-fly open a share/web folder/mount point just because you visit a webpage or click on a link in an E-mail. Windows does.

    Try out Gnome with GVFS or KDE with KIO. In Gnome there'll be an mount point in "~/.gvfs". It does, too.

Subscribe to our newsletter, Threatpost Today!

Get the latest breaking news delivered daily to your inbox.