Bug 42450

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 @).