Bugtraq mailing list archives
summary of recent glibc bugs (Re: SuSE Security Announcement: shlibs/glibc (SuSE-SA:2001:01))
From: Solar Designer <solar () OPENWALL COM>
Date: Sat, 27 Jan 2001 05:55:25 +0300
On Fri, Jan 26, 2001 at 03:55:17PM +0100, Roman Drahtmueller wrote:
The runtime-linker as used in the SuSE distributions ignores the content of the critical environment variables if the specified path begins with a slash ("/"), or if the library file name is not
s/begins with/contains/ (otherwise "../" attacks would be possible, which isn't the case)
cached (eg it is contained in a path from /etc/ld.so.conf). However, Solar Designer has found out that even preloading glibc- native shared libraries can be dangerous: The code in the user-linked
Thanks for crediting me, but this isn't exactly what my contribution was about. The fact that preloading "system" libraries can be dangerous was known before that (discussed a few years ago, including on Bugtraq). A solution was then introduced to require that the library be "SUID" for it to be LD_PRELOAD'able into SUID/SGID programs. On a typical system, there are no such libraries. My contribution was to point out that an exploit mentioned by Jakub Jelinek depended on this check not working. (I've also shown a way to exploit this property with glibc 2.1.x, but that isn't really my discovery as it was prompted by a ChangeLog entry for an attempt to fix that.) Ulrich Drepper committed a fix for this preload-non-SUID- library bug (which turned out to be in the caching you mention in the advisory) the next day. (My other contribution was proving that the LD_PROFILE{,_OUTPUT} handling was indeed a real vulnerability, as suspected by Daniel Jacobowitz.)
To eliminate these problems, we provide update packages that completely disregard the LD_* variables upon runtime-linking of a binary that has an effective uid different from the caller's userid.
I don't see that in SuSE package (libc-2.1.3-190.src.rpm), which seems to only contain the fixes from the glibc CVS (which are sufficient for the bugs we're currently aware of). I sent this summary to vendor-sec (even though most of the bugs were not discovered by me, this was just to ensure no vendor misses a fix relevant to versions of glibc they package): Date: Sat, 13 Jan 2001 03:00:34 +0300 (A few days after the fixes were committed.) | These are the (instances of) the recently discovered glibc bugs | (here "2.1" means 2.1 to 2.1.3, and "2.2" means 2.1.9x+): | | 1. LD_PRELOAD works for non-SUID libs even when running SUID/SGID. | | This affects both glibc 2.1 and 2.2. The proven way to abuse this | property is via libSegFault (overwrite any file), but even worse | attacks (providing a root shell directly) are likely to exist. | | Fixed in the CVS. | | 2. LD_PROFILE uses a file in /var/tmp even when running SUID/SGID. | | Both 2.1 and 2.2. The file is unsafely created and later mmap'ed | for processing. There're memory writes with addresses calculated | from data in the file, with no bounds checking. Thus, it definitely | is possible to overwrite files with this, and it might be possible to | get a root shell via this vulnerability directly. | | Fixed in the CVS by moving the profiling files to /var/profile (which | should only be created if the feature is desired) for the SUID/SGID | case. /var/tmp is still used for non-SUID/SGID programs if run with | LD_PROFILE set, which I dislike, but this is only a minor problem. | | 3. SEGFAULT_OUTPUT_NAME is trusted even when running SUID/SGID. | | Both 2.1 and 2.2. As the library isn't installed SUID by default, | this is only exploitable due to bug #1. | | Not fixed (the access() checks don't count). | | 4. MEMUSAGE_OUTPUT is trusted even when running SUID/SGID. | | 2.2 only (wasn't a part of glibc 2.1, but could be installed with it | as well). Similar to the SEGFAULT_OUTPUT_NAME. | | 5. RESOLV_HOST_CONF is trusted even when running SUID/SGID. | | 2.2 only. Fixed in the CVS. Date: Sun, 14 Jan 2001 14:44:56 +0300 | BTW, these recent bugs are now also fixed in glibc-2-1-branch, thanks | to Andreas Jaeger. The glibc 2.2 RESOLV_HOST_CONF bug which prompted this search for bugs was reported to Debian by Dale Thatcher but apparently wasn't kept private. The remaining bugs were discovered and dealt with within two days following the RESOLV_HOST_CONF bug report. As this bug got public, vendors were forced to not coordinate the release of updated glibc packages. -- /sd
Current thread:
- SuSE Security Announcement: shlibs/glibc (SuSE-SA:2001:01) Roman Drahtmueller (Jan 26)
- summary of recent glibc bugs (Re: SuSE Security Announcement: shlibs/glibc (SuSE-SA:2001:01)) Solar Designer (Jan 29)