Bug 9838
| Summary: | man bugs might lead to root compromise (RH 6.1 and other boxes | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | smedina |
| Component: | man | Assignee: | Bernhard Rosenkraenzer <bero> |
| Status: | CLOSED RAWHIDE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 6.0 | CC: | bjn |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2000-05-25 15:12:14 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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? 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. *** Bug 11037 has been marked as a duplicate of this bug. *** 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. |
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 SEGV: $ 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: ftp://dione.ids.pl/people/siewca/security/man/mkroot.9 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' code. Credit to: Michal Zalewski * [lcamtuf] <=> [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. <=-----=