Bugtraq mailing list archives
glibc user-supplied format strings. (why u should upgrade)
From: zenith parsec <zenith_parsec () THE-ASTRONAUT COM>
Date: Mon, 4 Sep 2000 12:07:29 -0000
***************************************************
* Extremely Serious Vulnerability in glibc *
* allows root compromise on multiple *
* distributions of Linux *
***************************************************
* zen-parse *
****************************************************************************
1.1 official release
1.0 unintetional early release.
http://www-gnats.gnu.org:8080/cgi-bin/wwwgnats.pl/full/1883
****************************************************************************
reply to that advisory...
The problem you've reported has been fixed in the development versions
(CVS) for glibc 2.1.x and glibc 2.2 just a few days ago:
--
Andreas Jaeger
SuSE Labs aj () suse de
****************************************************************************
so
/ ----------------------------
\/ -------- zen-parse -------
\/ ------------------------
\ /------- presents -----
\/ --------------------
\/ -------- a -------
\/ ----------------
\/ ---- huge ----
\/ ------------
[ Wrote 239 lines ]
[root@continuity /root]# cat glibc-advisory.txt
Subject: glibc user-supplied format strings. (why u should upgrade)
***************************************************
* Extremely Serious Vulnerability in glibc *
* allows root compromise on multiple *
* distributions of Linux *
***************************************************
* zen-parse *
****************************************************************************
1.1 official release
1.0 unintetional early release.
http://www-gnats.gnu.org:8080/cgi-bin/wwwgnats.pl/full/1883
****************************************************************************
reply to that advisory...
The problem you've reported has been fixed in the development versions
(CVS) for glibc 2.1.x and glibc 2.2 just a few days ago:
--
Andreas Jaeger
SuSE Labs aj () suse de
****************************************************************************
so
/ ----------------------------
\/ -------- zen-parse -------
\/ ------------------------
\ /------- presents -----
\/ --------------------
\/ -------- a -------
\/ ----------------
\/ ---- huge ----
\/ ------------
\/ ---hole---
\/ --------
\/ ------
\/ ----
\/ -
\/
**************************
<Attention getting part>
**************************
Vulnerable setuid programs that come on a standard Redhat 6.1 install
include, but are not limited to:
/bin/su
/bin/mount
/bin/umount
/usr/bin/at
/usr/bin/lpq
/usr/bin/passwd
/usr/bin/suidperl
/usr/sbin/usernetctl
/usr/sbin/userhelper
Scared yet?
***************************
</Attention getting part>
***************************
************************
Description of problem
************************
Suid root programs and i18n code. Bad sanity checking.
The environment variables involved in locale based function are not
(adequately?) sanity checked. I have not looked at the sources, but it
seems that although some programs (possibly the libc itself?) (seem to)
check that the values do not start with ../ for .mo files, they do not
(seem to) check the entire string, making it possible to step backwards
through the directory tree, after first taking a step forward, and to
anywhere you feel like. (e.g. /tmp/hack)
This problem, combined with appropriately formed format strings allows
arbitrary instructions to be executed by modifying the stack. Some fun
not-so-arbitrary instructions could be something like: jump to this code
setreuid(0,0);execl("/bin/sh","/bin/sh",0);
************************************
Proof of concept.
************************************
(user zen is an unprivileged user)
bash# export LANGUAGE=en_US/../../../../tmp/hack
bash# /usr/bin/strace -u zen su -c
...
--lots of strace output cut--
...
open("/usr/share/locale/en_US/../../../../tmp/hack/LC_MESSAGES/sh-utils.mo", O_RDONLY) = -1 ENOENT (No such file or
directory)
...
--lots more strace output cut--
...
bash#
it is possible to insert a string something like
%1$141x%81$hn%1$370x%82$hn%1$256x%83$hn%1$192x%84$hn
into a copy of sh-utils.mo and cause su to use it as the error message,
instead of
Mit `%s --help' bekommen Sie mehr Informationen.
(The difference in length isn't important for this purpose. The rest of
the file's strings aren't likely to be used.)
By manipulating the contents of of the arguments to su, you can cause the
program to execute arbitrary instructions.
For example, calling su this way:
execl("/bin/su",evil,"-c",0);
(where evil contains a string that contains pointers for the format string
to use to overwrite stack addresses, and shellcode to be executed)
will execute the shellcode with root permissions.
*****************************************************
remember: this is not a theoretical vulnerability
*****************************************************
I don't have any reason to believe this type of exploit is "in the wild",
but I have successfully used this method to gain root access to a
'wargame' running at roothat.labs.pulltheplug.com from an unprivileged
account.
(Actually, I don't know if all of the programs listed in the attention
getting part are definately exploitable for root, but at least some of
them are. I initially thought that pt_chown was vulnerable, but it does
setuid(geteuid()) before showing the error message. And that list isn't
complete either.)
roothat is a Redhat 6.2 with version 2.2.16 kernel, and 2.1.3 glibc.
I have also used it on my own machine. (Details above in the form thing
from /usr/bin/glibcbug.) I have not found any mention of this bug on the
web interfaced bug-tracking system linked from www.gnu.org, and so believe
this to be a newly found bug.
Although RH 6.1 doesn't come with any copies of sh-util.mo by default, it
is quite easy to come by a copy to edit, due to the all pervasive nature
of GNU software. (I found it on my windows partition :])
/mnt/C/cygnus/cygwin-b20/share/locale/de/LC_MESSAGES/sh-utils.mo
libc.mo could have been used if sh-util.mo was not available, with slight
modifications to the method used to exploit it. (libc.mo does exist in
several languages in a default install.)
This has also been checked on a Debian distribution, but only a simple
verification that the path problem existed was done. The format string
part is relatively easy to work out though.
Another approach is to create your own .mo files from scratch.
**********************************
The good news
**********************************
It's only exploitable locally. I think. Unless in.telnetd can somehow
accept locale environment variables. Maybe with ld.so bug as well? In
which case, if someone is able to upload a poisoned .mo file, you are well
and truly fucked.
*********************************************************************
the better news
*********************************************************************
Zen writes:Number: 1883 Category: libc Synopsis: sanity checking of locale paths/ .mo files - rootThe problem you've reported has been fixed in the development versions (CVS) for glibc 2.1.x and glibc 2.2 just a few days ago:
not a problem if u upgrade now, while stocks last
*********************************************************************
the rest of the stuff - the fun bits?
*********************************************************************
Trivia question :: imagine u have 2 ppl on one machine....
evil user benevolent/stupid root
terminal 1 (uid 500) terminal 2 (uid 0)
/tmp$ umask 220;touch /tmp/core
~# /some/prog that chdirs to /tmp
....
and crashes, dropping core...
/tmp$ ls -al /tmp/core
The question is: who owns /tmp/core?
+------------------------------------+
|..............zen-parse............ |
+-------------+----------------------+
#
# id -u
0
greets and stuff (coz thats what u do in advisories, isn't it?)
greetz:
lamagra, grue, laaz, dies, um... lets see... pfffff.... my minds gone
blank. lets see... everyone who uses [x]chat... um. everyone in #roothat
on irc.pulltheplug.com, most of the people in #wargames, my neice sarah,
my nephew daniel, possem, jon, brooke, murray, my parents, my sisters, my
brothers, all the people in COSC455 at cs.otago.ac.nz, um... everyone else
who is doing Philosophy and/or Computer Science anywhere in the world, and
anyone who wants to give me a job. (i can kind of code a little. amd prewf
read stuff and do grammer the spall gudely.)
evilz:
script kiddiez. may j00r attempts end up decea5ed or f1eaf00d.
(the format string given in the example writes the address
0xf1eaf00d to the stack at the address pointed to buy the
list of pointers at offsets 81-84, done this way to bypass
the problem of using a value that is too big for the format
string for the %n thing. (I could've probably done it in 2
writes, instead of 4, but I had the code for 4 lying around
from another exploit I wrote, and I am lazy.)
'-- advanced format string hacking' - zen-parse,
available when i get around to writing it)
For a list of some other words you can make with just hex, visit:
http://homepages.ihug.co.nz/~Sneuro/totaleleet.html
cabba6e5 is a nice one ;]
deadbeef still owns though.
If you are a music producer, or know someone who is, or just
want to get an idea of what i do when i'm not hacking, visit:
http://homepages.ihug.co.nz/~Sneuro/dx4.html
(or just /~Sneuro if u want to see some aging html/art/javascript)
my apologies if this sends twice.
Send someone a cool Dynamitemail flashcard greeting!! And get rewarded.
GO AHEAD! http://cards.dynamitemail.com/index.php3?rid=fc-41
Current thread:
- glibc user-supplied format strings. (why u should upgrade) zenith parsec (Sep 04)