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
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: man
Version: 7.2
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Eido Inoue
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks:
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:
Clone Of:
Environment:
Last Closed: 2003-06-02 09:58:22 UTC
Embargoed:


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.edu>
Organization: JHU ACM/CS/SRL
To: <bugtraq>


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/



Version-Release number of selected component (if applicable):
man-1.5i2-6

How reproducible:
Always

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

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.