Bug 42450 - man-1.5i-4: local->gid man-> root in update
Summary: man-1.5i-4: local->gid man-> root in update
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: man
Version: 7.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Bernhard Rosenkraenzer
QA Contact: Aaron Brown
Keywords: Security
Depends On:
TreeView+ depends on / blocked
Reported: 2001-05-27 11:39 UTC by Need Real Name
Modified: 2007-04-18 16:33 UTC (History)
1 user (show)

Clone Of:
Last Closed: 2001-07-10 04:00:14 UTC

Attachments (Terms of Use)
exploit for man-1.5i-4 (gid man) (2.74 KB, application/octet-stream)
2001-05-28 07:06 UTC, Need Real Name
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2001:072 high SHIPPED_LIVE : Updated man package fixing GID security problems. 2001-05-28 04:00:00 UTC

Description Need Real Name 2001-05-27 11:39:22 UTC
Affects:  man-1.5i-4

 gid man exploitable buffer overflow
 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

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 :

This problem being marked as CLOSED smacks of incompetence.

Comment 1 Bernhard Rosenkraenzer 2001-05-27 19:52:07 UTC
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 

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.

Comment 2 Bernhard Rosenkraenzer 2001-05-27 19:56:39 UTC
On a first look at the code, my_popen() seems to drop privileges before doing 

Comment 3 Bernhard Rosenkraenzer 2001-05-27 20:28:17 UTC
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?

Comment 4 Need Real Name 2001-05-28 07:06:44 UTC
Created attachment 19790 [details]
exploit for man-1.5i-4 (gid man)

Comment 5 Need Real Name 2001-05-28 07:11:05 UTC
to use the attachment:

compile 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)

Comment 6 Need Real Name 2001-05-28 07:25:42 UTC
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 change the LOCKFILE in /etc/cron.{daily,weekly}/makewhatis.cron 
to use some other dir that gid uucp can't write to.


that would prevent any possible creation of symlinks that the cron job
could execute.

Comment 7 Bernhard Rosenkraenzer 2001-05-28 07:32:09 UTC
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
I'll need to take a closer look.

Your suggestions look good; adding this.

Comment 8 Need Real Name 2001-05-28 08:34:31 UTC
(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.

Comment 9 Bernhard Rosenkraenzer 2001-05-28 13:37:38 UTC
You're right. Added.
I've also added "`" and "$(" to the list of invalid constructs in filenames.

Comment 10 Need Real Name 2001-05-29 12:54:41 UTC
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.

Comment 11 Need Real Name 2001-06-06 12:57:42 UTC
Another bug, MANPATH and PATH thing has already been released on bugtraq.

The bugzilla post on that,
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?)

Comment 12 Need Real Name 2001-07-10 04:00:11 UTC
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'
Instead of
 what is not forbidden is allowed
 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.

Comment 13 Bernhard Rosenkraenzer 2001-09-21 20:38:05 UTC
Fixed in 1.5i2-*

Still on a "no bad characters" basis: Too many man pages use unexpected 
characters (I've seen at least _, % and @).

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