Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Thu, 19 Feb 2015 22:19:23 +0000
From: Tim Brown <tmb@...35.com>
To: oss-security@...ts.openwall.com
Subject: Fixing the glibc runtime linker

A while ago, I suggested that I'd been working on glibc with regard to making 
it handle runtime linking more securely. Today, I finally managed to get a 
patch together which I think is worth sharing. I'd therefore like to issue a 
request for comments for the attached patch, and enquire if any distros feel 
like incorporating it? A few points on the rationale...

Why? 

Over the last couple of years I've spent a good deal of time dealing with 
vendors who, for one reason or another have shipped binaries where it is 
possible to inject "untrusted" code into running processes, notably but not 
exclusively via DT_RPATH.

What's the fix?

More often than not, the underlying issue is an empty element within the 
DT_RPATH header or equivalent. Sometimes it's not, but even in those cases, it 
is largely that one or more elements isn't qualifed (i.e. it doesn't start 
with /). The attached patch fixes this, by ignoring any elements of DT_RPATH, 
LD_LIBRARY_PATH that do not start with a /, and/or junking any use of dlopen 
where the filename is likewise unqualified.

Won't this break stuff?

Maybe (certainly it is means a change to glibc behaviour), but more often than 
not, the fact that a given binary currently works in an unsafe way is a bug - 
and an exploitable one at that. Moreoever, Solaris has had a similar sanitity 
check (in their case only for privileged setuid binaries) for a good number of 
years without serious incident. I believe we should be fixing software that 
exhibits the behaviour I've described, but this patch will (I think) kill the 
bug class irrespective of that.

Further thoughts?

The patch attached is the most robust variant I've produced in that it kills 
unqualified linker paths, irrespective of the privilege or otherwise of the 
affected binary. We could kill the checks for non-setuid binaries or we could 
add some additional errors in such cases. I did experiment with only checking 
a subset of cases (namely where LD_LIBRARY_PATH itself is set) if the process 
wasn't privileged, but in the end, I concluded that the loading of any 
unqualified linker path could provide an exploit vector (if the non-setuid 
binary is executed from a privileged process etc) and so erred on the side of 
caution. A useful variant of my patch for auditors is one that logs dangerous 
conditions rather than reject them outright, but I'm unconviced that it is 
helpful for the masses.

Tim
-- 
Tim Brown
<mailto:tmb@...35.com>

View attachment "no-unqualified-linker-paths.diff" of type "text/x-patch" (6122 bytes)

Download attachment "signature.asc " of type "application/pgp-signature" (820 bytes)

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.