OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: 3APA3A (3APA3ASECURITY.NNOV.RU)
Date: Fri Jul 13 2001 - 02:49:39 CDT

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    Hello,

    Topic: Special devices access in multiple archivers
    Author: 3APA3A <3APA3Asecurity.nnov.ru>
    Platform: Windows
    Affected Software: WinZIP Computing's WinZIP 8.0, PKWare PkZip
                              4.0, RARSoft WinRar 2.80
    Risk: average
    Released: July, 5, 2001
    SECURITY.NNOV advisories: http://www.security.nnov.ru/advisories

    Background:

    Archive extraction is usually treated by users as safe operation.
    There are a lot of problem with files extraction though.

    Problem(s):

    Among them: huge files with high compression ratio are able to fill
    memory/disk (see "Antivirus scanner DoS with zip archives" thread on
    Vuln-Dev), special device names and special characters in file names,
    directory traversal (dot-dot bug). All this issues are not new and are
    known to be exploited.

    Special device access is mostly Windows-specific problem (if not
    combined with path globing or directory traversal), because in Windows
    some devices are not located in specific place, but coexist in every
    directory (e.g. c:\temp\prn). Also file extension is ignored
    (c:\temp\prn.txt also refers to special device). Kernel mode drivers
    can create their own special devices. Special devices in Windows also
    represent physical disks, tapes, UNC names, and a lot of other
    devices. This kind of access can lead to system compromise. Same API
    functions are used to access special devices and ordinary files.
    That's why unchecked special device access should be treated as very
    serious and dangerous issue under Windows.

    If during extraction archiver doesn't check a name and type of
    destination file (e.g. using GetFileType() API) extracted file can be
    redirected to special device on archive creator's choice.

    Detailed info:

     WinZip 8.0:

     WinZip is vulnerable to special device problems. If archived file
     has name referring to special device it will be sent to this device
     silently. Authors contacted, but in fact I don't see any attempt to
     work this situation out:

    --quote helpwinzip.com
    WinZip will indeed have a problem with files which are named using what
    windows considers 'reserved' words; The windows operating system itself
    does not allow such words in filenames, although they may be considered
    perfectly valid under other operating systems.

    Please let me know if you have any questions.
    --quote helpwinzip.com--

    --quote from second message helpwinzip.com
    We are of course quite concious of the ramifications of the situation,
    and both the development staff and the QA personell are involved in
    addressing and testing such issues. Thanks for your concern.

    If you have any further questions or feedback, please don't hesitate to
    write.
    --quote from second message helpwinzip.com--

    It reminds me something from Mark Twain.

     PKWare PKZip 4.00:

     Is vulnerable. It doesn't detect special devices, but it detects
     existence of the file and asks confirmation from user before
     overwriting. If pkzip configured to overwrite files without prompt
     file will be extracted silently. Vendor contacted, but no feedback
     were given on this issue.

     RARSoft WinRAR 2.80

     WinRAR uses GetFileType() to determine type of target file, but fails
     to check FILE_TYPE_PIPE case. It leaves possibility to access some
     certain types of devices, including (but not limited to) prn, but
     most dangerous devices are filtered. Overwrite confirmation also
     required. According to Eugene Roshal problem will be completely fixed
     in nearest version.

     Archivers ported from Unix:

     Info-Zip's UnZip, Cygwin's port of tar and probably different ported
     archivers are vulnerable. DJGPP (GNU) DOS port of tar is safe (it
     uses stat() to check type of file and limitation of DOS API doesn't
     allow to access most dangerous devices).
     

    Exploitation:

     You can find archives with demonstration of PRN access on
     http://www.security.nnov.ru/advisories/archdos.asp

    Workaround:

     Test content of the archives before extraction if archive was
     obtained from untrusted source. Never automate extraction and never
     use administrator's account to extract data.

    Solution:

     Wait for vendor's patch or use safe archivers.

    -- 
    http://www.security.nnov.ru
             /\_/\
            { . . }     |\
    +--oQQo->{ ^ }<-----+ \
    |  3APA3A  U  3APA3A   }
    +-------------o66o--+ /
                        |/
    You know my name - look up my number (The Beatles)