COMMAND

    archivers

SYSTEMS AFFECTED

    WinZIP Computing's WinZIP 8.0, PKWare PkZip 4.0, RARSoft WinRar 2.80

PROBLEM

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

    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.

    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.   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.

    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).

SOLUTION

    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.  Wait for
    vendor's patch or use safe archivers.

    The  Anti-Virus  Test  Team  at  the  University of Magdeburg have
    looked at this issue about problematic filename like "AUX",  "NUL"
    or ".." inside archives  now on 39 security-related  programs like
    anti-virus scanners (Norton,  McAfee, CA, AntiVir,  AVX, Kaspersky
    etc.)  as  well  as   anti-trojan  programs  (Ants,   Anti-Trojan,
    Tauscan, etc.) To make it short: Most programs are not affected.

    The  first  test  includes  file  names like "NUL.EXE", "AUX.EXE",
    "LPT1.EXE" and  "CLOCK$.EXE" in  archive files  (please note, that
    "NUL" and  "NUL.EXE" have  exactly the  same behaviour,  they just
    used "EXE" to make  sure a scanner will  really try to check  this
    file in the archive). Archive types tested:  ZIP and ARJ.

    The  second  test  includes  file  names  like "../TEST.EXE" up to
    "../../../../../TEST.EXE" in ZIP archives.   No program drops  the
    TEST.EXE file somewhere on drive  C:.  All scanners who  found the
    original (not packed)  file were still  able to find  the virus in
    the  malformed  archive.   Therefore,  there  is no "scanner drops
    possible infected files" (Bat/WinRip issue) anymore - all  vendors
    have fixed possible problems at least one year ago.