Message-ID: <E19hycR-00029u-00@chiark.greenend.org.uk>
Date: Wed, 30 Jul 2003 22:36:23 +0100
From: Colin Watson <cjwatson@...ian.org>
To: bugtraq@...urityfocus.com
Subject: Re: man-db[] multiple(4) vulnerabilities.


In article <20030729210308.15518.qmail@....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@...ian.org]

Powered by blists - more mailing lists