exploit the possibilities

microsoft.wildcard.matches.txt

microsoft.wildcard.matches.txt
Posted Aug 17, 1999

Windows NT does not properly handle the use of wildcards, matching filename characters that do not even exist in pseudo-8.3 format filenames.

tags | exploit
systems | windows, nt
MD5 | fbf6d3fd21438b528956c3b83f52ea39

microsoft.wildcard.matches.txt

Change Mirror Download
Date: Mon, 14 Jun 1999 09:46:41 +0200
>From: BROWN Nick <Nick.BROWN@coe.int>
Subject: Unwanted wildcard match

I don't normally like to present individual bugs as RISKs, but this one just
bit me and is so counter-intuitive that I felt I had to report it.

It appears that when Windows NT (and, I imagine, other long-filename-enabled
Windows variants) matches a user-specified wildcard in a DOS prompt, it
matches the wildcard against both the full filename, and the pseudo-8.3
format filename.

For example, in a directory I have two files:
Shortcut to V1.LNK
Shortcut to V2.LNK

However, these were created in reverse order, which means that their
8.3-emulated names were also created in reverse order. So DIR/X shows:
Shortcut to V1.LNK SHORTC~2.LNK
Shortcut to V2.LNK SHORTC~1.LNK

Now, I wanted to get rid of "Shortcut to V1.LNK", and a number of related
files, so I typed
DEL *1.LNK
and "Shortcut to V2.LNK" disappeared as well.

The RISK ? With Microsoft, a wildcard can match a filename character that
you didn't even know was in the filename - indeed, which is part of a
compatibility system which I don't need to use. (There is no way to predict
a file's 8.3-emulated name from its full name - another magnificent piece of
non-design.)

Nick Brown, Strasbourg, France.

e-mail address updates : @coe.int replaces @coe.fr
for more information, http://dct.coe.int/info/emfci001.htm


[RISKS-FORUM Digest 20.44]

-------------------------------------------------------------------------------

Date: Wed, 16 Jun 1999 18:45:08 +0200
>From: BROWN Nick <Nick.BROWN@coe.int>
Subject: More on "Unwanted wildcard match" (RISKS-20.44)

I received quite a lot of mail on this subject. A couple of people
helpfully tried to explain what they thought was the problem, based on their
knowledge of DOS, but "assuming" that NT works that way, which it doesn't.
(RISKs of assuming next-generation systems are infelicity-compatible, I
guess.)

Yes, in DOS, the wildcards *1.LNK and *.LNK are identical, since DOS treats
* to mean "everything up to the period" (and there can only be one period).
However, NT's wildcard matching does more or less what you'd expect - it's
quite close to, say, how DCL does it under VMS. My problem is that it
matches both the visible and the invisible filenames.

For example, if I do this:

C:\>copy afile.txt longname2.txt
C:\>copy afile.txt longname1.txt
C:\>copy afile.txt longname4.txt
C:\>copy afile.txt longname3.txt
C:\>dir /x long*.*
LONGNA~2.TXT LongName1.txt
LONGNA~1.TXT LongName2.txt
LONGNA~4.TXT LongName3.txt
LONGNA~3.TXT LongName4.txt

> and delete *1.TXT, I "only" lose the first two files.
>
Footnote: Microsoft have, however, faithfully re-implemented in NT the
wonderful DOS bug whereby, if you change a file's extension while copying it
using a partial-match wildcard, the copy is done as if you said /A for
ASCII. For example, if I have WINWORD.EXE and I want to copy it to NICK.XXX
and I'm feeling lazy, I might say
> COPY W*.EXE NICK.XXX
without putting the /B switch on the COPY command.

> Try it - you'll get a file truncated to the offset of the first ctrl-Z
> character in the original.

Thanks also to the person who pointed out that the automatic note appended
to all outgoing e-mails from our site (saying that our domain name has
changed), which PGN didn't chop off as he sometimes does with voluble sigs,
contained a reference to a site which didn't work. Apparently this went
wrong about two weeks ago. Of the 80000 or so Internet E-mails we have sent
out since then, nobody else has bothered to mention the problem. This must
mean something.

Nick Brown, Strasbourg, France http://dct.coe.int/info/emfci001.htm


[Risks Digest 20.45]

-------------------------------------------------------------------------------

Date: Wed, 16 Jun 1999 13:40:41 -0500
>From: "Rumy Driver" <Rumy.Driver@sybase.com>
Subject: Re: Risks - Depending on a *.xxx convention for file types

This is to note we are still paying for the archaic way of using the *.xxx
extension for defining the file type.

This is only on Windows platforms which are a legacy of DOS days.

In most other platforms files have 2 parts (e.g. MacOS)
part1 resource fork
Contains the actual meta-data - program that created file, date of
creation, date of last modification ....
part2 data fork
Actual data

Now in the DOS-legacy world it is soooo easy to rename a file to another
extension and the file morphs itself. This is the sneaky trick/way used to
spread the latest virus/worm.

Another suggestion for *.ZIP files is NOT to double-click them and launch,
but to use the Classic mode of WinZip and check what is in the ZIP archive
before extraction. This would have let people know that it's a EXE file and
they could have taken precautions(?).

Another suggestion is not to have a completely homogeneous environment
(reminiscent of the potato"e" (apologies to Dan Quayle) famine)

Rumy Driver, Sybase Technical Support


[Risks Digest 20.45]

Comments

RSS Feed Subscribe to this comment feed

No comments yet, be the first!

Login or Register to post a comment

File Archive:

July 2019

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Jul 1st
    34 Files
  • 2
    Jul 2nd
    15 Files
  • 3
    Jul 3rd
    9 Files
  • 4
    Jul 4th
    8 Files
  • 5
    Jul 5th
    2 Files
  • 6
    Jul 6th
    3 Files
  • 7
    Jul 7th
    1 Files
  • 8
    Jul 8th
    15 Files
  • 9
    Jul 9th
    15 Files
  • 10
    Jul 10th
    20 Files
  • 11
    Jul 11th
    17 Files
  • 12
    Jul 12th
    16 Files
  • 13
    Jul 13th
    2 Files
  • 14
    Jul 14th
    1 Files
  • 15
    Jul 15th
    20 Files
  • 16
    Jul 16th
    27 Files
  • 17
    Jul 17th
    7 Files
  • 18
    Jul 18th
    5 Files
  • 19
    Jul 19th
    12 Files
  • 20
    Jul 20th
    0 Files
  • 21
    Jul 21st
    0 Files
  • 22
    Jul 22nd
    0 Files
  • 23
    Jul 23rd
    0 Files
  • 24
    Jul 24th
    0 Files
  • 25
    Jul 25th
    0 Files
  • 26
    Jul 26th
    0 Files
  • 27
    Jul 27th
    0 Files
  • 28
    Jul 28th
    0 Files
  • 29
    Jul 29th
    0 Files
  • 30
    Jul 30th
    0 Files
  • 31
    Jul 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2019 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close