Bugtraq mailing list archives

Re: Windows MS-DOS Device Name DoS vulnerabilities


From: 3APA3A <3APA3A () SECURITY NNOV RU>
Date: Fri, 6 Jul 2001 13:46:20 +0400

Hello ByteRage,

I completely disagree with your paper. It puts software developers and
users into false sense of security. Right now SECURITY.NNOV is working
out  few  MS-DOS  Device Name issues with vendors (not only in Windows
95/98/ME  but  also  in  NT/2000),  and  the  problem is definitely in
software,  not  in  operation system, because operation system behaves
exactly  as  expected  and  documented.  Later  we  will  publish  our
advisory.  Software  MUST check type of file it tries to access BEFORE
it  access  it,  if  this  can cause access to special device. Special
devices  under  Windows  allow raw access to ports, drives, tapes, etc
and  impact  of  such access can be same with impact of accessing /dev
under unix.

MS  patched one hole, which causes Windows 95/98/ME to crash then some
API call refer to any special device. This patch doesn't solve problem
of  special devices, because _successful_ access to such devices under
Windows can lead to much greater impact.

Also, enumeration of special device names is bad idea. New versions of
Windows     can     introduce     new     devices.    Eugene    Roshal
(http://www.rarsoft.com),  developer  of  well-known utilities Far and
Rar,  recommends  use  of GetFileType() API. In MS source examples you
can find a lot of:

if( GetFileType(hFile) != FILE_TYPE_DISK ) {
     lstrcpy( lpszPath, TEXT("Invalid File Type") );
     return( 0 );
   }

According  to  Mr.  Roshal  FILE_TYPE_CHAR and FILE_TYPE_PIPE probably
refer to special device names.

Checks  like  this  must be in "best coding practice", because even if
security  is  not  in question user can specify special device name by
accident.
   
Below is quote from message of Eli Zaretskii <eliz () is elta co il>, one
of  GNU  developers  (it was addressed to few developers, so I hope he
will not be against quoting):

-=-=-=-=-=-
Also,  `prn'  and  `lpt1'  are just a sample of the special names. Any
device driver which can be reached by opening a special file name will
cause  such  problems;  thus the list of the offending names cannot be
known  in advance, since additional device drivers can be installed on
the target system.

In  addition,  the  file-name  extension  is ignored when the basename
matches.  So  `aux.lst', `prn.c', `con.foo', and an infinite number of
other  similar  names--all  of them are prone to this problem. Some of
the  devices  will actually wedge the DOS box ... kids, don't try that
at home!
-=-=-=-=-=-


--Thursday, July 05, 2001, 1:34:28 PM, you wrote to bugtraq () securityfocus com:

B> of.  Because  the  flaw is within the operating system I think it's
B> obvious  that  the *operating system* itself is patched, instead of
B> rewriting  the  applications  running under it to have filtering...

B> 
CON,AUX,NUL,PRN,LPT1,LPT2,LPT3,LPT4,LPT5,LPT6,LPT7,LPT8,LPT9,COM1,COM2,COM3,COM4,COM5,COM6,COM7,COM8,COM9,CLOCK$,CONFIG$,XMSXXXX0,$MMXXXX0,MSCD000,DBLBUFF$,EMMXXXX0,IFS$HLP$,SETVERXX,SCSIMGR$,DBLSBIN$,
B> MS$MOUSE, etc... etc...

B> (I'm pretty sure that you can find a shitload more by
B> typing MEM /DEBUG |MORE in a DOS window or doing some
B> research)

http://www.security.nnov.ru

-- 
~/3APA3A
ЭНИАКам - по морде!  (Лем)



Current thread: