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:
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.”