Red Hat Bugzilla – Bug 42450
man-1.5i-4: local->gid man-> root in update
Last modified: 2007-04-18 12:33:26 EDT
Affects: man-1.5i-4 PROBLEM #1 gid man exploitable buffer overflow PROBLEM #2 root exploit from still vulnerable /usr/sbin/makewhatis Problem #2 requires prior exploitation of Problem #1 to exploit. ==================================================== Problem #1 is the buffer overflow. if the file is compressed, popen is used to both read in the file and determine the existance of files in the ultimate_source() function in man.c. the buffer overflow test appears to just make sure my_popen returns a success. If, by using shell metacharacters, you add extra commands that return true to the file, it will continue to accept file names much longer than the maximum filename length, as long as you can also make it read in as input the filename to look for next, by returning the extension to the search string as the argument to .so .so stringtoputintheoverflow/man1/somecommandwithmetacharescaping where somecommandwithmetacharescaping is an escape, a ' to close the one opened by the popen, the command in the path to execute (no spaces or /s allowed), and the command sequence ends in .gz, returning success is enough to let it continue processing. this overflow is exploitable, allowing arbitrary commands to be executed with gid man. ==================================================== Problem #2 involves to a very slight modification to the exploit given, and is in fact possible due to one of the bugs reported, in : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=41805 This problem being marked as CLOSED smacks of incompetence.
41805 is really fixed. We're bailing out if the filename contains any dangerous characters in 1.5i-6 or higher, just what the resolution of 41805 says. We fixed this in rawhide without releasing an errata because there was no known way to get gid man at that time. #1 is still a problem, fixing. The new version (which also has the fix for 41805) will be released as an errata, of course.
On a first look at the code, my_popen() seems to drop privileges before doing anything...
I've just read the code, and there doesn't seem to be a problem. Every part of the code uses my_popen() which is a wrapper around popen that drops privileges, so anything executed by man drops the setgid privileges. Am I overlooking something?
Created attachment 19790 [details] exploit for man-1.5i-4 (gid man)
to use the attachment: compile newman.c ./newman.c press Q after the 1st manpage is shown. after the garbage fills the screen, press return, then ^D you should end up in a shell with gid man. executing newman2root before or while /usr/sbin/makewhatis is running will allow creation of files as root. It is also possible that the contents of these files could be controlable. (still have to look into that)
How about this for an idea? chown root:root /var/cache/man (there doesn't seem to be any need for gid man to write to that directory) and and change the LOCKFILE in /etc/cron.{daily,weekly}/makewhatis.cron to use some other dir that gid uucp can't write to. LOCKFILE=/var/cache/man/makewhatis.lock that would prevent any possible creation of symlinks that the cron job could execute.
On my system, your newman.c exploit causes a segfault without giving any additional privileges after pressing ^D, on 7.1+updates; on rawhide, it doesn't even wait for ^D and gives [...]AAAAA/man1/: file name too long Segmentation fault immediately. I'll need to take a closer look. Your suggestions look good; adding this.
(the attached exploit is incredibly sensitive to initial conditions. ) What should work as a patch for the overflow: in src/man.c , ultimate_source (char *name0) . . . } else { strcat(name, "/"); strcat(name, beg); } + /* + if this is too long, bad things have already happened. + we should quit IMMEDIATELY. + */ + if(strlen(name)>sizeof(ultname)) _exit(1); goto again; . . . not the prettiest solution, but if someone is overflowing it, they are probably doing it deliberately, and don't deserve to get any results, valid or not.
You're right. Added. I've also added "`" and "$(" to the list of invalid constructs in filenames.
btw: change the address in the variable got to be the address from objdump -R /usr/bin/man |grep strcpy to get the exploit to work under rh 7.1 (in standard install) int b3=0, got=0x080515f8;// address of strcpy() in GOT in 7.1 standard forgot that would be different.
Another bug, MANPATH and PATH thing has already been released on bugtraq. http://www.securityfocus.com/archive/1/188445 The bugzilla post on that, http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=43213 now gives permission denied. This might make it difficult for people who are trying to verify the problem, or look for a fix. (Out of curiousity, why is that bug (which can give root if root views the apropriate page) hidden and this one, (which on the same systems can give root within 24hrs) not hidden? What is the policy on disclosure of bugs?)
Just thought of something else that might be an idea, and should prevent any future exploits based on something that might've been missed. Instead of checking for 'bad' characters, make sure it only contains 'good' chars. i.e.: Instead of what is not forbidden is allowed use what is not allowed is forbidden [A-Za-z0-9\.] I think would be enough? Not sure how this would work with different locale based names for things, but shouldn't break anything I can see.
Fixed in 1.5i2-* Still on a "no bad characters" basis: Too many man pages use unexpected characters (I've seen at least _, % and @).