Bug 87732 - CAN-2003-0124 man has a security bug which results in arbitrary codeexecution
Summary: CAN-2003-0124 man has a security bug which results in arbitrary codeexecution
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: man
Version: 7.2
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Eido Inoue
QA Contact: Ben Levenson
Depends On:
TreeView+ depends on / blocked
Reported: 2003-04-01 20:43 UTC by jian liu
Modified: 2007-04-18 16:52 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2003-06-02 09:58:22 UTC

Attachments (Terms of Use)

Description jian liu 2003-04-01 20:43:07 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.75 [en] (X11; U; Linux 2.4.3 i686)

Description of problem:
-------- Original Message --------
Subject: Vulnerability in man < 1.5l
Date: Tue, 11 Mar 2003 13:24:01 -0500 (EST)
From: Jack Lloyd <lloyd@acm.jhu.edu>
Organization: JHU ACM/CS/SRL
To: <bugtraq@securityfocus.com>

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.


$ cat innocent.1
.so "".1
$ cat '"".1'  # the outer '' quotes are for the shell
the user will never see this
$ cat `which unsafe`

echo "oops"
id -a
$ man ./innocent.1
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

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. follow the example in the report.

Additional info:

Comment 1 Mark J. Cox 2003-04-02 08:38:46 UTC
This is CAN-2003-0124.  We are treating this as a low priority (a system would
have to allow the creation of a malicious man page and the victim would need have
to have a program called 'unsafe' on their path)

Comment 2 Mark J. Cox 2003-06-02 09:58:22 UTC
This was fixed on May01 by RHSA-2003:133

Note You need to log in before you can comment on or make changes to this bug.