Bug 42450 - man-1.5i-4: local->gid man-> root in update
man-1.5i-4: local->gid man-> root in update
Status: CLOSED ERRATA
Product: Red Hat Linux
Classification: Retired
Component: man (Show other bugs)
7.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bernhard Rosenkraenzer
Aaron Brown
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-05-27 07:39 EDT by Need Real Name
Modified: 2007-04-18 12:33 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-07-10 00:00:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description Need Real Name 2001-05-27 07:39:22 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.
Comment 1 Bernhard Rosenkraenzer 2001-05-27 15:52:07 EDT
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.
Comment 2 Bernhard Rosenkraenzer 2001-05-27 15:56:39 EDT
On a first look at the code, my_popen() seems to drop privileges before doing 
anything...
Comment 3 Bernhard Rosenkraenzer 2001-05-27 16:28:17 EDT
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 03:06:44 EDT
Created attachment 19790 [details]
exploit for man-1.5i-4 (gid man)
Comment 5 Need Real Name 2001-05-28 03:11:05 EDT
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)
Comment 6 Need Real Name 2001-05-28 03:25:42 EDT
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.
Comment 7 Bernhard Rosenkraenzer 2001-05-28 03:32:09 EDT
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.
Comment 8 Need Real Name 2001-05-28 04:34:31 EDT
(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 09:37:38 EDT
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 08:54:41 EDT
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.
Comment 11 Need Real Name 2001-06-06 08:57:42 EDT
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?)
Comment 12 Need Real Name 2001-07-10 00:00:11 EDT
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.

Comment 13 Bernhard Rosenkraenzer 2001-09-21 16:38:05 EDT
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.