At 04:46 AM 7/6/2001, 3APA3A wrote:
>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.
The hole that ByteRage discussed was most _definitely_ a flaw in system
security, wherein merely trying to open a file with a path name that
contained two DDNs would cause a BSoD. Your suggested workaround of
GetFileType() requires a handle to an open file, which you cannot get
without (tada!) opening the file, which itself would have caused the crash.
>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.
This is a second issue with device names, and is not touched on by
ByteRage's initial posting in this thread. You aren't disagreeing with
ByteRage, you're posting something additional that just happens to share
the detail of access to devices through file-like paths.
>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:
Enumeration of special devices, by an API, would be most useful, because
then an application could prohibit access to device names _prior_ to having
to open the file. Should there be future bugs discovered in opening device
specifiers, it'd be nice to be able to say "filter all input paths and
remove any specification that matches a device name". Currently, there is
no API to do this.
>According to Mr. Roshal FILE_TYPE_CHAR and FILE_TYPE_PIPE probably
>refer to special device names.
According to the documentation:
FILE_TYPE_UNKNOWN - The type of the specified file is unknown.
FILE_TYPE_DISK - The specified file is a disk file.
FILE_TYPE_CHAR - The specified file is a character file, typically an LPT
device or a console.
FILE_TYPE_PIPE - The specified file is either a named or anonymous pipe.
>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.
A list compiled programmatically at the start of operation would be
somewhat more useful. While it's true that additional device drivers can
be installed while a program is running, I wonder if these are given DDNs?
>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!
The person quoted here doesn't indicate whether it is merely opening the
device files, or trying to access (read or write) their contents, is what
will "wedge the DOS box" - if the former, then GetFileType is sadly of no
assistance.
Alun.
~~~~
--
Texas Imperial Software | Try WFTPD, the Windows FTP Server. Find us at
1602 Harvest Moon Place | http://www.wftpd.com or email [EMAIL PROTECTED]
Cedar Park TX 78613-1419 | VISA/MC accepted. NT-based sites, be sure to
Fax/Voice +1(512)378-3246 | read details of WFTPD Pro for NT.
