[16535] in bugtraq
Serious vulnerability in glibc
daemon@ATHENA.MIT.EDU (=?latin1?Q?Jouko_Pynn=F6nen?=)
Mon Sep 4 16:20:53 2000
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=latin1
Message-ID: <Pine.LNX.4.10.10009022017480.2749-100000@shell.solutions.fi>
Date: Sat, 2 Sep 2000 20:24:11 +0300
Reply-To: =?latin1?Q?Jouko_Pynn=F6nen?= <jouko@SOLUTIONS.FI>
From: =?latin1?Q?Jouko_Pynn=F6nen?= <jouko@SOLUTIONS.FI>
To: BUGTRAQ@SECURITYFOCUS.COM
Content-Transfer-Encoding: 8bit
PROBLEM DESCRIPTION
A vulnerability exists in glibc versions up to version 2.1.3, ie. all released
versions, allowing local users to get root access. Fix packages for most major
Linux distributions have been released or will be released within a day or two.
There's also a quick workaround described below. Note that this is different
from the "unsetenv" bug discussed earlier on this list.
The bug is exploitable if 1) there exists a suid/sgid installed program
that uses the locale functions of glibc, and 2) the standard locale
_directories_ exist in /usr/share/locale/. Unfortunately, all common Linux
installations to my knowledge fulfill these two conditions by default.
There are numerous programs that can be used for exploiting this bug. Anything
that's setuid/setgid and calls gettext() is dangerous, however not necessarily
exploitable. The function is also called in an exploitable way from some other
common libc functions such as getopts(). With an exploit script I've been able
to get root access using at least the following programs: at, chage, crontab,
login, mount, rlogin, su, umount. The problem has been tested on RedHat 6.0
and 6.1, Debian, Slackware, and LinuxPPC-1999. However the list of exploitable
programs varies between different distributions.
BUG DETAILS
Since all released glibc versions are vulnerable, it wouldn't probably serve
the purpose to go in the goriest details now. That's why this description is
a mere outlining of the problem, although more details will follow later.
The effective part of the bug resides in locale file loading functions. Some
careless code in there fails to detect if a user defineable locale file is
inside the default locale directory hierarchy (/usr/share/locale/) or outside
it. The result is that a malicious user can feed his/her own locale files and
that way, translation strings to locale-aware programs. These strings are
often used as format strings in setuid root programs which leads to problems
as seen in recent exploits.
WORKAROUND
A quick workaround is to remove (or move elsewhere) the files under
/usr/share/locale/ until the library itself has been fixed; or simply
mv /usr/share/locale /usr/share/locale.old
VENDOR PATCHES
Linux distribution vendors have been informed and they will submit related
advisories to this list. Some pointers:
RedHat: RHSA-2000:057-02
http://www.redhat.com/support/errata/RHSA-2000-057-02.html
Debian: packages will be listed soon on http://security.debian.org/
Conectiva: updated files on ftp://atualizacoes.conectiva.com.br,
advisory soon at http://www.conectiva.com.br/atualizacoes
CREDITS & ACKNOWLEDGEMENTS
Vulnerability discovered by: Jouko Pynnönen
Thanks and greets to: Esa Etelävuori, vendor-sec team, glibc-team
cc-opers/IRCNet, Solar Designer
--
Jouko Pynnönen Online Solutions Ltd Secure your Linux -
jouko@solutions.fi http://www.secmod.com
