Home    |    View Topics    |    Search    |    Contact Us    |   



Category:   Application (Generic)  >   UnZip Vendors:   Info-ZIP
UnZip Lets Malicious Tar Files Write to Windows Devices When Extracted
SecurityTracker Alert ID:  1002005
SecurityTracker URL:
CVE Reference:   GENERIC-MAP-NOMATCH   (Links to External Site)
Date:  Jul 16 2001
Impact:   Host/resource access via network, Modification of system information
Exploit Included:  Yes  

Description:   SECURITY.NNOV reported that a vulnerability in the UnZip file archive extraction utility allows malicious tar file archives to write to Windows devices when the tar file is extracted.

If the tar archive contains a file with a file name that is the same as a Windows device name, the UnZip utility will cause the contents of the file to be written to the device. It is reported that file extensions on that file will be ignored by Windows.

Devices may include printers, physical disks, tape drives, UNC names, and other devices.

UnZip reportedly does not check the name and type of destination file before redirecting the contents to the device name of the archive creator's choice.

A demonstration exploit tar file is available at:

Impact:   A malicious tar file can write to a device with the privileges of the UnZip user when the tar file is extracted.
Solution:   No solution was available at the time of this entry.
Vendor URL: (Links to External Site)
Cause:   Input validation error
Underlying OS:  Windows (Me), Windows (NT), Windows (95), Windows (98), Windows (2000)

Message History:   None.

 Source Message Contents

Subject:  archive extraction DOS device access vulnerability

Topic:                    Special devices access in multiple archivers
Author:                   3APA3A <>
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:


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, because in
Windows  some  of  devices are not located in some specific place, but
are  placed 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.  For example, user with administrator's privileges can
access    physical   disk   (including   MBR)   via   special   device
\\.\PhysicalDrive#  under  Windows  NT/2000.  This  access can lead to
system  compromise.  Same  API  functions  are  used to access special
devices and ordinary files. That's why 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
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

-- quote from second message
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
-- quote from second message

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 writing.
 If  pkzip  configured  to overwrite files without prompt file will be
 overwritten 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()).


 Given  archives  <A style="fixed"
HREF="/files/archive/"></A>,  <A style="fixed"
HREF="/files/archive/prntest.rar">prntest.rar</A>,  <A style="fixed"
HREF="/files/archive/prntest.tar">prntest.tar</A> contain file
 with  PRN  name.  It should print one text page on device attached to
 PRN  on  extraction  (PRN refers by default to LPT1, you need printer
 installed  on  LPT1  in  order  to  test  it.  You needn't to connect
 printing  device  -  just install any driver). Try to extract it with
 your favorite archiver.


 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.


Go to the Top of This SecurityTracker Archive Page

Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2021, LLC