Sign Up for Your FREE Weekly SecurityTracker E-mail Alert Summary
|
|
|
|
|
|
|
Put SecurityTracker Vulnerability Alerts on Your Web Site -- It's Free!
|
|
|
|
Become a Partner and License Our Database or Notification Service
|
|
|
|
|
|
|
|
|
|
|
|
|
(Vendor Issues Fix) Re: 'man-db' Buffer Overflows Let Local Users Execute Arbitrary Code
|
|
SecurityTracker Alert ID: 1007344 |
|
SecurityTracker URL: http://securitytracker.com/id/1007344
|
|
CVE Reference:
GENERIC-MAP-NOMATCH
(Links to External Site)
|
Date: Jul 31 2003
|
Impact:
Execution of arbitrary code via local system, User access via local system
|
Fix Available: Yes Vendor Confirmed: Yes
|
Version(s): 2.4.1 and prior
|
Description:
Several vulnerabilities were reported in 'man-db'. A local user can cause man-db to execute arbitrary code.
Vade79 reported a buffer overflow in the add_to_dirlist() function in the 'src/manp.c' file. MANDATORY_MANPATH, MANPATH_MAP, and MANDB_MAP values are not properly validate to limit their size. According to the report, this overflow by itself can (likely) only be used to overwrite characters in the buffer and not to execute arbitrary code. However, a local user can reportedly supply large values that can trigger overflows in other functions.
The report indicates that many functions allocate buffers of 4095 bytes, but a local user can pass values of 8192 bytes.
A demonstration exploit transcript is provided:
# cd /tmp
# mkdir x
# echo MANDB_MAP `perl -e 'print"x"x8100'` x >~/.manpath
# mandb
It is also reported that the ult_src() function in the 'src/ult_src.c' file contains an incorrect buffer size (that is too small) for the 'path' variable. A local user may be able to execute arbitrary code.
A demonstration exploit is provided:
# man -M `perl -e 'print"/"x2100'`usr/share/man ls
It is also reported that the software does not perform bounds checking for linked '.so' man pages.
A demonstration exploit transcript is provided:
# cd /tmp
# mkdir man man/man1
# echo .so `perl -e 'print"x"x1024'` >man/man1/x.1
# man -M /tmp/man x
Finally, several overflows were reported in the processing of user-supplied PATH/MANPATH values.
A demonstration exploit is provided:
# man -M `perl -e 'print"/tmp:"x260'` x
|
Impact:
A local user may be able to cause man-db to execute arbitrary code with set group id (setgid) 'man' group privileges.
|
Solution:
The vendor has issued a fix, available via CVS at:
http://savannah.nongnu.org/
Fixes for Debian Linux are pending.
The vendor plans to issue a fixed version (2.4.2) shortly.
|
Cause:
Boundary error
|
Underlying OS:
Linux (Any), UNIX (Any)
|
|
Message History:
This archive entry is a follow-up to the message listed below.
|
Source Message Contents
|
Date: Wed, 30 Jul 2003 22:36:23 +0100
Subject: Re: man-db[] multiple(4) vulnerabilities.
|
In article <20030729210308.15518.qmail@www.securityfocus.com>
on chiark.mail.bugtraq, Vade 79 wrote:
[...]
Thank you for reporting these vulnerabilities in man-db. However, I'm
disappointed that you neither informed me a little beforehand so that I
wasn't taken by surprise by your BugTraq post (preferable), nor sent a
copy of your report to me as the maintainer of man-db (which I would
regard as the minimum of common courtesy). Fortunately, a friend brought
your post to my attention this morning so that I could begin preparing
patches, a little later than I would otherwise have been able to do.
Please inform the maintainer in future. The BugTraq guidelines suggest a
one-week notice period, although in fact I'd personally have been happy
with a few days.
>[part 1: add_to_dirlist() buffer overflow]
>
>man-db contains a buffer overflow vulnerability do to the lack of bounds
>checking in multiple sscanf() calls. which formats the user supplied file
>~/.manpath.
[...]
>as you can see; MANDATORY_MANPATH, MANPATH_MAP, and MANDB_MAP do not
>properly limit the value written to key[50], and/or cont[512]). however,
>as far as exploitation by overflowing those buffers goes is limited. this
>is do to the way the buffers are allocated in memory, so when
>overwritten, will just overwrite into another character buffer.
>
>but, this is not all in vain. do to the size of buf[BUFSIZE], which is
>8192 bytes(standard), and what key/cont overwrites into. you can pass
>enormously long values(~8192) to other functions. as most checks are done
>before-hand, and almost all buffers in the program are allocated to 4095
>bytes; you can make the overflow occur, in many locations, elsewhere in
>the program.
I've fixed the sscanf() invocations so that these arrays aren't
overflowed. Other PATH_MAX-sized buffers will take a little more work,
but I'll look at them.
>[part 2: ult_src() buffer overflow]
>
>man-db contains a buffer overflow vulnerability do to the size of a buffer
>being half the size it should be(doesn't follow the 4096 trend), for a
>"path".
Fixed by allocating this buffer dynamically instead.
>[part 3: ".so" link buffer overflow]
>
>man-db contains a buffer overflow vulnerability do to the lack of bounds
>checking for ".so" link/redirection manpages. this occurs when the
>function attempts to change memory, without re-calculating the
>size.
Fixed in the process of fixing part 2 above, by causing the function in
question to return a newly allocated string rather than doing that
grotty hack of writing into a string allocated elsewhere without
reallocation.
>[part 4: PATH/MANPATH argument overflow]
>
>man-db contains a buffer overflow vulnerability do to the lack of bounds
>checking for the amount PATH/MANPATH values given. the bug is found in
>multiple routines.
>
>proof/to test for vulnerability existence:
># man -M `perl -e 'print"/tmp:"x260'` x
>Segmentation fault
On my machine it seems to require 432 elements or more, but anyway. I've
applied a stopgap measure for now, namely to check whether the number of
elements in MANPATH is going to overflow the list holding them. I'll add
proper dynamically resized arrays later when I have a little more time.
These fixes are in savannah.nongnu.org CVS for now; I'll prepare a
release for Debian unstable tonight and if possible Debian stable as
well. A full 2.4.2 release will have to wait a little longer, but should
be within the week.
Cheers,
--
Colin Watson [cjwatson@debian.org]
|
|
Go to the Top of This SecurityTracker Archive Page
|