SECURITY.NNOV: special devices access in multiple archivers

[3APA3A <3APA3A () SECURITY NNOV RU>]

Hello,

Topic:                    Special devices access in multiple archivers
Author:                   3APA3A <3APA3A () security 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 help () winzip 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 help () winzip com--

--quote from second message help () winzip 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 help () winzip 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)