Winrar doesn't determine the actual size of compressed files+possibility of DoS attack on server!

From: hUNTER 007 (door_hunt3r_at_blackcodemail.com)
Date: 09/10/03

  • Next message: Liu Die Yu: "MSIE->WsOpenFileJPU" 
    Date: 10 Sep 2003 03:46:46 -0000
To: bugtraq@securityfocus.com
    ('binary' encoding is not supported, stored as-is)

    ---[ about WinRAR]---
    Winrar (http://www.rarsoft.com/) is one of the most popular file
    compression utilities for Windows.

    --[summary]---
    Winrar incorrectly determines the actual size of compressed files saved
    in .rar format by reading it's header information.

    --[details]--
    Recently we managed to devise a technique to spoof the header and
    creating a valid CRC checksum. Later we found that Winrar only depends on
    it's header information and CRC check sum to determine the size and
    integrity of .rar files. Before uncompressing .rar files, Winrar pre-
    allocates space according to the actual file size specified in the header
    to avoid fragmentation.But pre-allocation occurs without checking the
    available hdd space. Then it goes extracting, even if the hdd size is
    less than the size of the files.We did a test by extracting 1GB files in
    a hdd with 700MB free space.

    Surprisingly, we later discover that even in detecting of header
    corruption WinRAR doesn't enforce to avoid extraction process. this lead
    WinRAR to believe that the actual size is correct .We managed to exploit
    this and create a proof of concept to demonstrate this problem by
    changing the actual file size in it's header. When it starts extracting
    it doesn't find any valid data in the archive and on the basis of it's
    header it attempts to extract 1 gigabyte of data and simply goes on
    writing "0x00" filling up valuable hdd space.

    --[Proof of concept]--
    The proof of concept is a valid .rar file which is just 100 bytes but
    it's header has been forged to fool Winrar into thinking that it's a 1
    gigabyte file by forging it's header and creating a valid CRC checksum.
    All versions of Winrar (upto 3.20 - latest version till date) seem to be
    vulnerable.

    The proof of concept of .rar file can be obtained from the following URL:
    http://www.geocities.com/visitbipin/test123.zip
    If you extract the file Winrar will try to extract this 100 bytes .rar
    file trusting the information in it's header but not on the basis of it's
    data integrity.

    --[Background Information]--
    This bug was originally discovered by hUNT3R, a member of 01 Security
    Sumbission. The vendor was notified via email. Further discussion took
    place in 01 Security Sumbission's forum with the developer of Winrar
    (Eugene Roshal) :
    URL: http://www.ysgnet.com/phorum/read.php?f=1&i=341&t=324#reply_341

    ---[about 01 security submission]---
    01s.s is a small group having experience as security specialists,
    programmers and system administrators
    http://www.ysgnet.com/hn.
    --------------------------
    An email from full-disclosure with bug verification and patch!
    --------------------------
    This looks very bad to me.

    I've tested it on a Linux machine with unrar 2.71, which comes with most
     distributions. Same unrar binary is used by anti-virus scanner.

    Result is the following:

    $ unrar x -v test123.rar

    UNRAR 2.71 freeware Copyright (c) 1993-2000 Eugene Roshal

    Extracting from test123.rar

    Extracting MAIL.DWN
    MAIL.DWN - CRC failed
    Total errors: 1

    As CRC failed, unrar will delete this file immediately but during the
    extraction it'll create nice 1GB file.

    As I wrote above, same unrar binary is used by anti-virus scanner
    (amavisd-new
     in this case), so this is creates a very nasty possibility of DoS
    attack on servers.

    Solution is to download and install the latest version from WinRAR's
    Website:

    <http://www.rarlab.com/rar_add.htm>

    Particulary, for Unix/Linux get it's source:

    <http://www.rarlab.com/rar/unrarsrc-3.2.3.tar.gz>

  • Next message: Liu Die Yu: "MSIE->WsOpenFileJPU"

    Relevant Pages