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 <elizat_private>, 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 bugtraqat_private: 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 ÝÍÈÀÊàì - ïî ìîðäå! (Ëåì)
This archive was generated by hypermail 2b30 : Fri Jul 06 2001 - 10:08:49 PDT