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
