Bugzilla Bug 17385

Vulnerability in man < 1.5l 
 
From:  
Jack Lloyd <lloyd@acm.jhu.edu>  (JHU ACM/CS/SRL) 
 
 
To:  
<bugtraq@securityfocus.com> 
 
 
Date:  
Yesterday 19.24.01 
 
 
man 1.5l was released today, fixing a bug which results in arbitrary code 
execution upon reading a specially formatted man file. The basic problem 
is, upon finding a string with a quoting problem, the function my_xsprintf 
in util.c will return "unsafe" (rather than returning a string which could 
be interpreted by the shell). This return value is passed directly to 
system(3) - meaning if there is any program named `unsafe`, it will execute 
with the privs of the user. 
 
Example: 
 
$ cat innocent.1 
.so "".1 
$ cat '"".1' # the outer '' quotes are for the shell 
the user will never see this 
$ cat `which unsafe` 
#!/bin/sh 
 
echo "oops" 
id -a 
$ man ./innocent.1 
oops 
uid=528(lloyd) gid=100(users) groups=100(users) 
$ 
 
The location of the man pages and the binary are basically irrelevent, as 
long as: 
 
1) man can find the man pages somewhere; both man pages have to be in the 
   same subtree due to how man handles .so directives. /usr/share/man/man* 
   works fine, as does the local directory (./manpage.1) case 
2) the shell can find `unsafe` somewhere in $PATH 
 
The severity of this depends on lot on your systems, but is generally not 
very high. People running systems with publicly writeable contrib 
directories should probably do a quick `find . -name unsafe` just to be 
sure. Average home users probably don't have much to worry about, nor do 
most corporate environments. 
 
A simple workaround is to symlink /bin/unsafe to /bin/true. man 1.5l is not 
vulnerable to this problem. 
 
I would like to thank Andries Brouwer, the current `man` maintainer, for 
his fast response. Sources for the new version can be found at 
ftp://ftp.win.tue.nl/pub/linux-local/utils/man/

glsa sent