bugtraq - Vulnerability in man

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.33L2.0303071650440.15995-100000@centaur.acm.jhu.edu>
Date: Tue, 11 Mar 2003 13:24:01 -0500 (EST)
From: Jack Lloyd <lloyd@....jhu.edu>
To: <bugtraq@...urityfocus.com>
Subject: Vulnerability in man < 1.5l

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/