Vulnerability in man < 1.5l

2003-03-12T00:00:00
ID SECURITYVULNS:DOC:4194
Type securityvulns
Reporter Securityvulns
Modified 2003-03-12T00:00:00

Description

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/