Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
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:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
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.

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.