Re: man bugs might lead to root compromise (RH 6.1 and other

From: Elias Levy (aleph1at_private)
Date: Wed Mar 01 2000 - 11:59:37 PST

  • Next message: Peter Wemm: "Re: SSH & xauth"

    Summary of comments on ths thread:
    
    "Dehner, Ben" <Btdat_private>:
    
    HPUX 10.20 also does not have suid/sgid /usr/bin/man, so I would guess is
    not exploitable.
    
    Thomas Molina <tmolinaat_private>:
    
    babcia padlina exploit did not work under RedHat 6.1
    
    Przemyslaw Frasunek <venglinat_private>:
    
    so try other offsets. -1000 should work on most redhat 6.1/6.0/5.2 boxes.
    
    Stefan Schneider <stefan.schneiderat_private>:
    
    No problems here...
    
    Tested on SuSE 6.3, no SIGSEV either.... The box is a regular SuSE 6.3
    install (No patches, fresh install from the CD's) and the package status
    is man-db ver 2.3.10-69d69i.
    
    kraselat_private-wuerzburg.de (Cornelius Krasel):
    
    SuSE man (at least on SuSE 6.3 which is the same version) uses PAGER
    instead of MANPAGER and blissfully crashes when subjected to 4000 'A'
    letters in this variable.
    
    I didn't manage to get the redhat exploit to work properly, but I
    got several times "sh: =FC=FF=BF: command not found" which indicates to
    me that a more skillful programmer than me would be able to get it
    to work.
    
    Phil Stracchino <alaricat_private>:
    
    Slackware 7.0 does not appear to be vulnerable.  /usr/bin/man is not
    setgid in slackware, so although it does indeed SEGV at the expected
    location, no privileges are gained.
    
    "Licquia, Jeff" <JLicquiaat_private>:
    
    On my aforementioned Debian system, this fails with:
    
    sh: AAAA...AAAA: command not found
    man: command exited with status 32512: /bin/gzip -dc
    '/var/cache/man/cat1/ls.1.gz' | { export MAN_PN LESS; MAN_PN='ls(1)';
    LESS="$LESS\$-Pm\:\$ix8mPm Manual page $MAN_PN ?ltline %lt?L/%L.:byte
    %bB?s/%s..?e (END):?pB %pB\\%.."; AAAA....AAAA; }
    
    (AAA's truncated for readability)
    
    Greg Olszewski <noopat_private>:
    
    This does not create a sigsegv on Debian GNU/Linux slink, potato, or woody.
    With man -V of:
    slink:
    man, version 2.3.10, db 2.3.1, July 12th, 1995 (G.Wilfordat_private)
    debian version 2.3.10-69FIX.1, (Jun  9 1999),  Fabrizio Polacco
    +<fpolaccoat_private>
    
    potato & woody:
    man, version 2.3.12, Wed Feb 23 00:00:00 EET 2000 (fpolaccoat_private)
    
    It was tried setting both MANPAGER and PAGER. In each case, 4000 and 20000
    were tried, and sh:<a lot of A's> command not found was echoed to stderr.
    
    The lack of a sgid bit on /usr/bin/man is the default configuration
    for both potato and woody.
    
    Scott Lamb <slambat_private>:
    
    On my RedHat 6.1 system, this does NOT appear to be exploitable. The reason
    is: the execution of arbitrary commands is done while processing the troff
    macros: while generating the catman pages from the man pages. Merely
    viewing the preformatted pages does not allow commands to be executed.
    
    So it is not exploitable without access to the man (*.[1-9]) pages. On
    RedHat 6.1, these are owned by root. Exploiting the buffer overflow in
    man gives you a chance to be annoying and send nasty messages to people when
    they run man, but not gain root priveleges.
    
    Bob Billson <bobat_private>:
    
    Same here on two different Linux boxen, running Debian (Slink and
    Potato).
    
    H D Moore <hdmat_private>:
    
    I tested this on a stock RedHat 6.1 box and it wouldnt segfault unless
    at least 4534 characters were in the buffer.  With some twiddling on the
    command line I got it to jump to arbitrary addresses with:
    
    $ MANPATH=`perl -e 'print "A" x 4534 . "BBBB"'`
    
    ^-- this makes jump to 0x42424242
    
    Anyways, anyone feel like writing an exploit?
    
    Julian Squires <tekat_private>:
    
    I could equally not reproduce this on several Debian machines,
    running:
    man, version 2.3.10, db 2.3.1, July 12th, 1995 (G.Wilfordat_private)
            debian version 2.3.10-69s, (Oct 28 1999),  Fabrizio Polacco <fpolaccoat_private>
    
    as well as:
    man, version 2.3.10, db 2.3.1, July 12th, 1995 (G.Wilfordat_private)
            debian version 2.3.10-71, (Feb 11 2000),  Fabrizio Polacco <fpolaccoat_private>
    
    /usr/bin/man is setuid man under debian, and I attempt with both
    PAGER and MANPAGER variables, with strings up to 65536 bytes in length.
    
    What version of man is vulnerable to this?
    
    Marcin Owsiany <porridgeat_private>:
    
    Tested on Debian potato
    
    ii  man-db         2.3.12         Display the on-line manual.
    
    and slink (2.1)
    
    ii  man-db          2.3.10-69FIX.1 Display the on-line manual.
    
    both PAGER and MANPAGER set to a length from 400 to 40000 Bytes.
    No SIGSEGV
    
    Dylan Griffiths <Dylan_Gat_private>:
    
    Slackware Linux 7.0 is not setgid man, and the /var/man/cat directories are
    owned root.root, but have the same sticky bit as the /tmp directory.
    So Slackware is likely secure from any man exploits.
    
    Kris Kennaway <krisat_private>
    
    FreeBSD uses the GNU man code, but it seems we fixed this (along with a
    bunch of other overflows) back in '96..
    
    From: Luca Berra <blucaat_private>:
    
    this is man_db a different program than standard linux man.
    past versions had bugs of their own, check bugtraq archives
    
    Thomas Bader <thomasbat_private>:
    
    I could not reproduce this too. I'm using Debian GNU/Linux 2.1 .
    "man --version" says:
    
    | man, version 2.3.10, db 2.3.1, July 12th, 1995 (G.Wilfordat_private)
    |       debian version 2.3.10-68, (Oct  6 1998),  Fabrizio Polacco <fpolaccoat_private>
    
    And "ls -l /usr/bin/man" says:
    
    |-rwsr-xr-x   1 man      root       119864 Oct  6  1998 /usr/bin/man
    
    I tried the enviroments PAGER and MANPAGER, but they both didn't work.
    
    
    
    --
    Elias Levy
    SecurityFocus.com
    http://www.securityfocus.com/
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:38:28 PDT