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
