Bugzilla – Bug 687510
VUL-0: CVE-2011-0536: glibc: $ORIGIN RPATH fix now causes searching in working dir
Last modified: 2016-11-03 09:31:19 UTC
Your friendly security team received the following report via oss-security. Please respond ASAP. The issue is public. The fix for CVE-2010-3847 introduces a regression that causes the linker to search the current working directory. An additional patch is needed: http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=96611391ad8823ba58405325d78cefeae5cdf699 CVE-2011-0536
see also http://sourceware.org/bugzilla/show_bug.cgi?id=12393
Ok, I have tracked down the source of all the confusion. Unfortunately the sourceware bugreport did not help things at all and it didn't occur to me to verify if the patch all the fuss is about is something we actually carry. The CVE-2011-0536 pretty much covered three different issues - $ORIGIN being perhaps too liberally allowed, $ORIGIN abuse in LD_AUDIT and more generic issue with LD_AUDIT. We (and upstream glibc) focused only on the LD_AUDIT aspect of things in the end, which was also all the focus of the advisory. Fedora received an extra patch that attempted to fix a general problem of $ORIGIN being expanded in rpaths of setuid-started processes. If attacker has write access to the filesystem of the binary, they can hardlink the binary to a directory under their control and therefore feed the binary further libraries through the compromised runpath. HOWEVER, the hardlink abuse is possible only in case the setuid binary itself has been compiled with $ORIGIN rpath. As far as I know, we do not ship any such binary and one could argue this to be a very foolish thing to do at link time. We are vulnerable, but I think this is very rare condition and the impact of this is overall low. The patch on Fedora's branch was 4b646a51f, but it was misguided. It prevents any expansion of $ORIGIN within setuid-started processes (not just the main binary, but also any other shared objects). In particular, gconv modules refer to libJIS with $ORIGIN rpath. Since $ORIGIN is not expanded, $ORIGIN in current directory is considered and arbitrary code can be loaded through $ORIGIN/libJIS.so. This vulnerability, for a change, is rather high impact; now most setuid programs using iconv() could be exploited trivially. But we do not carry the fix for the original vulnerability and therefore are not vulnerable for this. The alternative to the upstream fix is Fedora fix 96611391. Instead of not expanding $ORIGIN within setuid-started process, it is expanded to an empty string - BUT only for the main program binary, references within libraries will be expanded as usual. The patch is problematic as the resulting empty rpath still triggers search in the current directory; this essentially reinstates the very original $ORIGIN vulnerability. Two followup patches are required then. In summary, we are vulnerable to a rather obscure bug that requires a small maze of patches to fix properly. I think it's best to wait for upstream to finally take the cummulative fix now, rather than dig ourselves a bigger hole. Alternatively, we can consolidate the patches to a single one and apply it with a hope that it does not add any more bugs (I did not catch anything when going through it), and therefore fix the obscure $ORIGIN bug.
Ok, I have been wrong to a degree, as pointed out in the sourceware.org bug. The $ORIGIN non-expansion problem also occurs in our branch, but only if the rpath contains $ORIGIN not alone but with some extra path. Again, this is not nearly as serious as the problem in Fedora since we do not build any binary with such a setup to my knowledge. However, it is not possible to prevent the issue by isolating setuid binaries to filesystem with no user write access anymore; in my mind, that feels a bit more serious than before. I will provide a patch for upstream that also performs appropriate white-listing of ok $ORIGIN directories as Ulrich required.
My proposed approach that seems to fix the bug for me is http://sourceware.org/bugzilla/attachment.cgi?id=5684 - it would be great if we could wait a bit now to give the upstream some chance to react.
any news? do you have the bugreport too (not just the attachment? ;)
The bugreport itself is the aforementioned http://sourceware.org/bugzilla/show_bug.cgi?id=12393 I've got positive feedback from Tomas Hoger, no feedback from upstream but who knows how more time that would take. So I think we can go with this patch. Shall I start resubmitting?
then i would say: lets go.
Submitted everywhere now.
Update released for: glibc, glibc-32bit, glibc-debuginfo, glibc-debuginfo-32bit, glibc-debuginfo-64bit, glibc-debuginfo-x86, glibc-debugsource, glibc-devel, glibc-devel-32bit, glibc-html, glibc-i18ndata, glibc-info, glibc-locale, glibc-locale-32bit, glibc-locale-x86, glibc-obsolete, glibc-profile, glibc-profile-32bit, glibc-profile-x86, glibc-x86, nscd Products: SLE-DEBUGINFO 11-SP1 (i386, ia64, ppc64, s390x, x86_64) SLE-DESKTOP 11-SP1 (i386, x86_64) SLE-SDK 11-SP1 (i386, x86_64) SLE-SERVER 11-SP1 (i386, ia64, ppc64, s390x, x86_64) SLES4VMWARE 11-SP1 (i386, x86_64)
Update released for: glibc, glibc-32bit, glibc-64bit, glibc-dceext, glibc-dceext-32bit, glibc-dceext-64bit, glibc-dceext-devel, glibc-dceext-x86, glibc-debuginfo, glibc-devel, glibc-devel-32bit, glibc-devel-64bit, glibc-html, glibc-i18ndata, glibc-info, glibc-locale, glibc-locale-32bit, glibc-locale-64bit, glibc-locale-x86, glibc-obsolete, glibc-profile, glibc-profile-32bit, glibc-profile-64bit, glibc-profile-x86, glibc-x86, nscd Products: SLE-DEBUGINFO 10-SP4 (i386, ia64, ppc, s390x, x86_64) SLE-DESKTOP 10-SP4 (i386, x86_64) SLE-SDK 10-SP4 (i386, ia64, ppc, s390x, x86_64) SLE-SERVER 10-SP4 (i386, ia64, ppc, s390x, x86_64)
Update released for: glibc, glibc-devel, glibc-html, glibc-i18ndata, glibc-info, glibc-locale, glibc-profile, nscd, timezone Products: Novell-Linux-POS 9 (i386) Open-Enterprise-Server 9 (i386) SUSE-CORE 9 (i386, ia64, ppc, s390, s390x, x86_64)
*** Bug 1008255 has been marked as a duplicate of this bug. ***