[21383] in bugtraq
Re: Windows MS-DOS Device Name DoS vulnerabilities
daemon@ATHENA.MIT.EDU (Michael Poole)
Sat Jul 7 15:04:44 2001
To: bugtraq@securityfocus.com
From: Michael Poole <poole@troilus.org>
Date: 06 Jul 2001 13:23:44 -0400
In-Reply-To: <114170563437.20010706134620@SECURITY.NNOV.RU>
Message-ID: <87u20qc6ov.fsf@cj46222-a.reston1.va.home.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
3APA3A <3APA3A@SECURITY.NNOV.RU> writes:
> 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.
Having a specification that says something doesn't make it a good
spec. I agree with ByteRage -- it is a fault in the OS (and its
specification) for the OS to parse file names specially regardless of
location in the filesystem hierarchy, simply because it opens up so
many security-related bugs.
> 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.
The notable difference is that in Unix, the system administrator has
control over where device files exist. Under Windows, they exist
_automatically_, in every directory. That's why it is such a problem
for applications running under Windows platforms, and (I believe) why
device files are not considered a serious problem for Unix-like
platforms.
If Microsoft keeps the current behavior for backwards compatibility,
then your conclusions about using functions such as GetFileType()
(rather than enumerating names) hold; but one can always hope that
the OS's behavior will be fixed.
-- Michael
