Re: Windows MS-DOS Device Name DoS vulnerabilities

[ByteRage <byterage () yahoo com>]

--- 3APA3A <3APA3A () SECURITY NNOV RU> wrote:
> Hello ByteRage,
>
> I completely disagree with your paper. It puts
> software developers and users into false sense of
> security.

Users should indeed be aware that the OS patch
introduces new possibilities for attackers
(accessibility of devices instead of a crash), but I
still see it as a first step in more 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.

The 'blue screen' problem of win95/98/ME is not the
behaviour that is expected and I really doubt whether
it would be documented :) The crash problem was
definitely within the operating system. Off course,
when applying the patch, the problem arises that these
special devices won't crash the OS but that they will
be accessible. As I said in my post : "the OS patch is
better because it fixes *ALL* problems, and if it
wouldn't then that's where this discussion should be
about" with *ALL* problems I meant : the crashing
using whatever devices. And now that this has been
fixed, we can start the discussion about what
applications should do with these accessible devices.

> 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.

Unfortunately, most software doesn't do this type of
checking, they just see if the device names match with
the well known ones, which either results in a crash
or an accessible device. Most posts to bugtraq deal
with the DoS possibility though.

> 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.

Enumeration is a very bad idea, the reason why I gave
some of the devices is because I wanted to show that
they cannot be enumerated at all. Unfortunately, this
type of filtering is used alot in applications (simply
checking whether the device names match a certain
list).

> 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.

devices should indeed not be accessible via some
applications, but neither should they crash the
operating system
    
> 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...

I was wrong about this : certain applications should
have filtering, but via bulletproof techniques that
filter *ALL* devices (using calls to the OS that make
it possible to identify if it is a device) and making
these devices unaccessible, because they can be used
malicously when accessible.
Furthermore, the win95/98/SE operating system should
be patched as well so that it doesn't crash when
devices are accessed which was the main item of my
previous post.


> 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$,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
> ÝÍÈÀÊàì - ïî ìîðäå!  (Ëåì)

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/