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.