Following patch was applied to glibc packages to address dynamic linker privilege escalation issue CVE-2010-3847 (see bug #643306): https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2010-3847#c26 http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=4b646a51f13fd6816c483fb24c308a13264c6d1a This change introduced a regression in handling of privileged programs that use $ORIGIN in R*PATH in the binary itself, or any of the depending libraries. When running such privileged program, this issue causes dynamic linker to not expand $ORIGIN in R*PATH and search for additional dynamic objects starting from the current working directory. This could allow a local user to escalate their privileges, or cause the program to fail to find required libraries. Prior to the CVE-2010-3847, it was possible to escalate privileges when privileged program had $ORIGIN in R*PATH. An attacker needed to have a write access to the file system hosting such binary, to be able to hard-link it to an attacker-controlled directory. Then the attacker could LD_PRELOAD malicious library from the same directory and execute code with elevated privileges. This flaw was of limited risk, as setuid/setgid binaries with $ORIGIN in R*PATH seem to be rare (there's no such binary in Red Hat Enterprise Linux). With the 4b646a51 fix applied, attacker no longer needs write access to the file system with privileged program, and the relative-to-CWD search can be triggered by R*PATHs of depending libraries too. Even with these loosened requirements, there are currently no privileged programs shipped with Red Hat Enterprise Linux known to be exploitable using this flaw. To address this issue, 4b646a51 was reverted and the following patch was applied in fedora glibc git branch: http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=96611391ad8823ba58405325d78cefeae5cdf699 Following patch is also required to avoid regressing CVE-2010-3847 fix: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2010-3847#c22 http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=22cd1c9bcf57c5829d65b6da825f7a459d40c9eb
(In reply to comment #0) > To address this issue, 4b646a51 was reverted and the following patch was > applied in fedora glibc git branch: > http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=96611391ad8823ba58405325d78cefeae5cdf699 This fix has not been applied to glibc master branch yet as discussed in the following libc-hacker mailing list thread: http://sourceware.org/ml/libc-hacker/2010-12/msg00001.html It seems the change was rejected because it removes useful and desired behaviour of having $ORIGIN supported privileged programs' R*PATHs. The discussion does not seem to mention risks of the feature though. Andreas, have there been any other off-list discussions of this change?
Public now via Debian advisory DSA 2122-2: http://lists.debian.org/debian-security-announce/2011/msg00005.html and Ubuntu advisory USN-1009-2: https://lists.ubuntu.com/archives/ubuntu-security-announce/2011-January/001226.html using patches listed in comment #0.
(In reply to comment #0) > To address this issue, 4b646a51 was reverted and the following patch was > applied in fedora glibc git branch: > http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=96611391ad8823ba58405325d78cefeae5cdf699 F13 glibc-2.12.2-1 ld.so with this patch applied still searches CWD.
If you can create a suid-root program all bets are off.
(In reply to comment #8) > If you can create a suid-root program all bets are off. There are two cases here: - problem with gconv that was introduced as part of CVE-2010-3847 fix. This may lead to privilege escalation if some suid program uses gconv and it's the issue we need to address (e.g. by reverting "Never expand $ORIGIN in privileged programs" and adding "Don't expand DST twice in dl_open") - second, there are issues that can lead to privilege escalation when you have suid with odd RPATH. While such suids are not common, users can unintentionally introduce them in their systems and create and exposure that ld.so can (should?) mitigate. It's probably worth discussing if linked should provide safety net for such cases, or these can be ignored as way too uncommon to be worth changing current status quo. Hence I've created upstream bug that can be used to discuss if current behaviour is appropriate or not: http://sourceware.org/bugzilla/show_bug.cgi?id=12393
Raising impact rating to important. Additional exploitation vectors have been demonstrated, which affect common configurations.
This issue has been addressed in following products: Red Hat Enterprise Linux 5 Via RHSA-2011:0412 https://rhn.redhat.com/errata/RHSA-2011-0412.html
This issue has been addressed in following products: Red Hat Enterprise Linux 6 Via RHSA-2011:0413 https://rhn.redhat.com/errata/RHSA-2011-0413.html
(In reply to comment #12) > Raising impact rating to important. Additional exploitation vectors have been > demonstrated, which affect common configurations. Will these vectors be disclosed at some point? When?
(In reply to comment #15) > Will these vectors be disclosed at some point? When? Reporter indicated an intention to make exploit public after waiting some time to give users and downstream distros an opportunity to pick up the fix.