[21370] in bugtraq
Re: Windows MS-DOS Device Name DoS vulnerabilities
daemon@ATHENA.MIT.EDU (3APA3A)
Fri Jul 6 13:08:15 2001
Date: Fri, 6 Jul 2001 13:46:20 +0400
From: 3APA3A <3APA3A@SECURITY.NNOV.RU>
Reply-To: 3APA3A <3APA3A@SECURITY.NNOV.RU>
Message-ID: <114170563437.20010706134620@SECURITY.NNOV.RU>
To: ByteRage <byterage@yahoo.com>
Cc: bugtraq@securityfocus.com
In-Reply-To: <20010705093428.46243.qmail@web13007.mail.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=Windows-1251
Content-Transfer-Encoding: 8bit
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
ÝÍÈÀÊàì - ïî ìîðäå! (Ëåì)
