[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <201502192219.29436.tmb@65535.com>
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.
