Re: man-db[] multiple(4) vulnerabilities.

From: Colin Watson (cjwatsonat_private)
Date: Wed Jul 30 2003 - 14:36:23 PDT

  • Next message: Matt Zimmerman: "[SECURITY] [DSA-355-1] New gallery packages fix cross-site scripting"

    In article <20030729210308.15518.qmailat_private>
    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                                       [cjwatsonat_private]
    



    This archive was generated by hypermail 2b30 : Wed Jul 30 2003 - 15:08:48 PDT