Bug 87732 - CAN-2003-0124 man has a security bug which results in arbitrary codeexecution
CAN-2003-0124 man has a security bug which results in arbitrary codeexecution
Status: CLOSED ERRATA
Product: Red Hat Linux
Classification: Retired
Component: man (Show other bugs)
7.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Eido Inoue
Ben Levenson
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-04-01 15:43 EST by jian liu
Modified: 2007-04-18 12:52 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-06-02 05:58:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description jian liu 2003-04-01 15:43:07 EST
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 (Product Security) 2003-04-02 03:38:46 EST
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 (Product Security) 2003-06-02 05:58:22 EDT
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.