Bugzilla – Bug 648020
CVE-2010-3847 reported potentially allowing local privilege escalation
Last modified: 2010-10-27 01:56:32 UTC
+++ This bug was initially created as a clone of Bug #648017 +++ [Cloned for OpenSUSE] OpenSUSE 11.x glibc-2.11.2-3.1.1.x86_64 A vulnerability in the C libraries has been reported. Links and the full contents are included below for convenience: http://seclists.org/fulldisclosure/2010/Oct/257 https://wiki.egi.eu/wiki/EGI_CSIRT:Alerts/liblinker-2010-10-18 <quote> Introduction ============ Earlier today, Tavis Ormandy released information about a vulnerability in GNU libc, complete with an exploit that on many systems can give any local user root privileges. (For full details, see the link below.) This vulnerability has been labelled CVE-2010-3847, and is present on many Linux distributions, including RHEL/CentOS/SL 5 (but *not* RHEL 3 and 4 and their derivatives). Vendor patches are not yet available. Details ======= As far as is known, the vulnerability can only be exploited if users can write to a file system that contains binaries with suid root permissions. (Since it is necessary for the attacker to create a hard link to a suid root binary.) This is, for instance, the case if /bin is located on the same filesystem as /tmp (or any other user writable location, like /var/tmp, /home, /var/lib/texmf, and so on). This is unfortunately a common configuration. Mitigation ========== To make it impossible to make the required hard link, directories containing suid/sgid binaries can be made to appear to as separate file systems by doing mount -o bind /sbin /sbin for each such directory. Please note that these commands must be re-run whenever the system is rebooted, for example by adding them to a suitable init script. A baseline list of directories with suid/sgid binaries on a typical RHEL 5 system is: /bin /sbin /usr/bin /usr/libexec /usr/lpp /usr/sbin You should check for any additional site specific locations using a command like find / -type f \( -perm /u+s -o -perm /g+s \) that will list all files with suid/sgid permissions. </quote>
thank you for the report. We are also already tracking this in non-public bug 646960. Currently, we believe this is not exploitable in SUSE glibc since we do not compile with -DNDEBUG and an assert() catches this condition.
However, much more serious problem popped up as a follow-up: http://thread.gmane.org/gmane.comp.security.full-disclosure/75807 This is very easily exploitable, even on OpenSUSE. We are preparing a security update. The only known workarounds are not very convenient - either block all setuid programs for the time being, or go through all libraries in /lib and /usr/lib and move away those with dangerous constructors (as outlined in the advisory). To be safe at least against script kiddies, just do away with libpcprofile and the lftp modules, however more savvy attackers might find other problematic .sos.
second problem got CVE-2010-3856 (for cross referencing)
Workarounds: - for the posted script kiddie exploit: rm /lib*/libpcprofile.so rpm -e lftp (will deinstall the ftp client) - setuid binary vector: disabling all setuid bits is likely not a good idea and will break the system for various usages. it can be done by changing /etc/sysconfig/security to: PERMISSION_SECURITY="paranoid local" and running "SuSEconfig --module=permissions" (paranoid removes all setuid bits) Again, please be aware this will break stuff like "su", "sudo", "at" etc.
Fixes for all opensuse branches were submitted.