Bug 87732

Summary: CAN-2003-0124 man has a security bug which results in arbitrary codeexecution
Product: [Retired] Red Hat Linux Reporter: jian liu <jian.liu>
Component: manAssignee: Eido Inoue <havill>
Status: CLOSED ERRATA QA Contact: Ben Levenson <benl>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.2Keywords: Security
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-06-02 09:58:22 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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