Bug 9838 - man bugs might lead to root compromise (RH 6.1 and other boxes
Summary: man bugs might lead to root compromise (RH 6.1 and other boxes
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: man   
(Show other bugs)
Version: 6.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Bernhard Rosenkraenzer
QA Contact:
: 11037 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2000-02-28 19:17 UTC by smedina
Modified: 2008-05-01 15:37 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-05-25 15:12:14 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description smedina 2000-02-28 19:17:12 UTC
The purpose of this email is twofold: 1) to inform you of a reported
vulnerability involving one of your products, and 2) to obtain
confirmation/clarification and knwoledge of any measures taken to address
this in the event it is viable.

Below is the report (snipped):

Subject: man bugs might lead to root compromise (RH 6.1 and other boxes)

With most of Linux distributions, /usr/bin/man is shipped as setgid man.
This setgid bit is required to build formatted manpages in /var/catman for
faster access. Unfortunately, man does almost everything via system()
calls, where parameters are user-dependent, and almost always it's
sprintf'ed before to fixed size buffers. It's kinda trivial to gain man
privledges, using buffer overflows in enviromental variables. For example,
by specyfing MANPAGER variable with approx 4k 'A' letters, you'll get

$ MANPAGER=`perl -e '{print "A"x4000}'` man ls


1200  setuid(500)                       = 0
1200  setgid(15)                        = 0
1200  open("/usr/share/locale/pl/man", O_RDONLY) = -1 ENOENT (No such file
or directory)
1200  open("/usr/share/locale/pl/LC_MESSAGES/man", O_RDONLY) = -1 ENOENT
(No such file or directory)1200  open("/usr/share/locale/pl/man",
O_RDONLY) = -1 ENOENT (No such file or directory)
1200  open("/usr/share/locale/pl/LC_MESSAGES/man", O_RDONLY) = -1 ENOENT
(No such file or directory)1200  close(-1)                         = -1
EBADF (Bad file descriptor)
1200  write(2, "Error executing formatting or display command.\nSystem
command (cd /usr/man ; (echo
1200  --- SIGSEGV (Naruszenie ochrony pamijci) ---
1200  +++ killed by SIGSEGV +++

Program received signal SIGSEGV, Segmentation fault.
0x41414141 in ?? ()

As you can see, SEGV occours when we're at privledged level (after setgid
man) and is trivially exploitable (generic stack overflow). What then? We
have 'man' privledges and write access to /var/catman directory tree (less
interesting, can be used to mess around with man output), and, usually, to
some /usr/man files (it shouldn't be possible, but some compilers, like
cpp, and programs like fetchmail, for some reasons have g+w manpages on
many systems). Days ago, Pawel Wilk described possible vulnerability in
manpage processing - execution of arbitrary code when evil manpage is
being browsed... Sample manpage is available at:


So, if you have write access to some manpages, and root uses man, there's
a chance to gain root privledges. If not, only lusers are affected.

I have no information on other Unices, except for *BSD, where it seems to
be patched days ago, and SunOS, which seems to be vulnerable, but isn't
setuid/setgid (am I right? only one system tested).

Solution: remove sgid bit from /usr/bin/man (it will be no longer creating
preformatted manpages in /var/catman), or rewrite major portions of 'man'

Credit to:
Michal Zalewski * [lcamtuf@ags.pl] <=> [AGS WAN SYSADM]
[dione.ids.pl SYSADM] <-> [http://lcamtuf.na.export.pl]
[+48 22 551 45 93] [+48 603 110 160] bash$ :(){ :|:&};:
=-----=> God is real, unless declared integer. <=-----=

Comment 1 bjn 2000-02-28 20:13:59 UTC
Two exploits were also posted to bugtraq today, one specifically for RedHat.
We're movin' at Internet speed!

One posted suggested disabling man page caching as a solution -- what about
making this the default for root?

Comment 2 Bernhard Rosenkraenzer 2000-02-28 20:26:59 UTC
We've verified there are a couple of buffer overruns in man that allow you to
get setgid man, and are working on fixing this. Since there are several possible
overruns and the whole design of the man program is not made for safety, it's
not something that can be done in an hour or two.

However, there is NO possible root exploit, since the .pso macro is limited to
safe binaries. (try viewing the mkroot.9 man page mentioned in the bug report -
it doesn't do anything harmful).

The scope of the buffer overrun is that you might be able to get setgid man (we
don't have any man-writable pages in /usr/man), and can write to files in
/var/catman, to present false information to other users (but not execute
programs, because .pso is disabled).
This is an annoying, but hardly critical security problem.

A quick fix is disabling preformatted man pages (remove FSSTND from
/etc/man.config); this is not a good thing because of speed considerations
though. If you're paranoid about system security, it's a good workaround until
we've come up with a real fix.

Comment 3 Preston Brown 2000-05-25 14:41:59 UTC
*** Bug 11037 has been marked as a duplicate of this bug. ***

Comment 4 Preston Brown 2000-05-25 15:12:59 UTC
while there were buffer overflows present in man, and these have been corrected
for later releases, I cannot make the exploit here work as it is intended under
Red Hat Linux 6.1 or 6.2.

Also, review of bugtraq seems to indicate that while buffer overflows are
present, it is a false alarm to claim they are exploitable.

Unless someone can come up with an exploit that works, I'm going to hold off on
releasing an errata update.

Note You need to log in before you can comment on or make changes to this bug.