Slashdot Mirror

Not to mention the medieval esh, ezh, thorn, and yogh; which, I understand, are pronounced with subtle differences against their Roman transliterations: sh, zh, th and gh.

Not to mention the medieval esh, ezh, thorn, and yogh; which, I understand, are pronounced with subtle differences against their Roman transliterations: sh, zh, th and gh.

http://www.fileformat.info/info/unicode/char/2756/ browsertest.htm

It is found in the Miscellaneous Symbols category in the Character Palette in Mac OS X.

The best description I've found of the WMF format is here. Based on this information, it looks as if a filter can look at the first four bytes of a file and identify it as a WMF document with very few false positives.

Doing this with discrete files might not be too bad. Applying this check to every part of a MIME document, or to various compressed file formats, could get very painful.

Use border firewalls to rewrite the first few bytes of all files matching the magic number for WMF. That number is 9AC6CDD7h, according to MS http://www.fileformat.info/format/wmf/egff.htm. If the WMF recognition is based entirely on magic, then damaging the file and changing the extension should block recognition and therefore processing. Don't have control of a firewall to test it myself, sorry. -JD

I once had to chase down what appeared to be a webserver problem, that eventually turned out to have been caused by Windows incorrectly autodetecting a filetype based upon the "Magic String".

The server was set up to archive files generated by our operations folk. These files are plain old ASCII text, and have no file extensions. One particular file was constantly coming up as an invalid file format in the browser. Remoting into the server and opening the file in vi showed no problems, it looked like any other text file in the archive.

After much hair pulling and gnashing of teeth, I eventually tried to do a 'Save link as...' to download the file to the Windows box, and discovered the file save dialog was defaulting to Windows Bitmap (BMP). Turns out that the 'Magic String' for the BMP file format is an ASCII 'BM' in the first two bytes of the file. This text file started with those two characters.
Reference BMP: http://www.fileformat.info/format/bmp/egff.htm#MIC BMP-DMYID.3.2/

Apparently when Microsoft designed the BMP format, they assumed that nobody would ever use those two characters to begin a text file. They probably also assumed that any text file would have a TXT file extension. Since file extensions don't really mean anything to the OS in the Unix/Linux world, we never saw a need to put extensions on these files.

At any rate, after seeing first hand how easily Windows can incorrectly autodetect a file type, I have no problem believing this attack can succeed with an extension other than WMF. The black hat just makes sure his attack has the right magic string in it and he can give it any extension he wants.
Reference WMF: http://www.fileformat.info/format/wmf/#MICMETA-DMY ID.3.1/

I once had to chase down what appeared to be a webserver problem, that eventually turned out to have been caused by Windows incorrectly autodetecting a filetype based upon the "Magic String".

The server was set up to archive files generated by our operations folk. These files are plain old ASCII text, and have no file extensions. One particular file was constantly coming up as an invalid file format in the browser. Remoting into the server and opening the file in vi showed no problems, it looked like any other text file in the archive.

After much hair pulling and gnashing of teeth, I eventually tried to do a 'Save link as...' to download the file to the Windows box, and discovered the file save dialog was defaulting to Windows Bitmap (BMP). Turns out that the 'Magic String' for the BMP file format is an ASCII 'BM' in the first two bytes of the file. This text file started with those two characters.
Reference BMP: http://www.fileformat.info/format/bmp/egff.htm#MIC BMP-DMYID.3.2/

Apparently when Microsoft designed the BMP format, they assumed that nobody would ever use those two characters to begin a text file. They probably also assumed that any text file would have a TXT file extension. Since file extensions don't really mean anything to the OS in the Unix/Linux world, we never saw a need to put extensions on these files.

At any rate, after seeing first hand how easily Windows can incorrectly autodetect a file type, I have no problem believing this attack can succeed with an extension other than WMF. The black hat just makes sure his attack has the right magic string in it and he can give it any extension he wants.
Reference WMF: http://www.fileformat.info/format/wmf/#MICMETA-DMY ID.3.1/

http://www.fileformat.info/info/unicode/char/ffe4/ index.htm

Cheers,
Matt

<copyright>&copy;2003-2005, A9.com, Inc. or its affiliates.</copyright>

You would think they would get that one right given that unicode A9 is the © symbol.

Unicode 00A9

It's similar to the claims that international support in mozilla was a vulnerability. It isn't. the USER is the vulnerabitlity, educate the user and the vast majority of these problems will go away.

While I agree with you to some extent, you picked a really poor example there. The international characters in the URL toolbar are really very deceptive. Allow me to offer you two picture links.

Letter "a"
Letter "a"

Now you tell me which one is the cyrillic character, and which is the roman character. I don't know about you but my eyes are not that good! It would be trivial for some one to mask their domain in a link as another domain, provided the spoofed domain has a roman letter "a" in it anywhere. You could even set up a proxy server to listen for connections to something like https://paypal.com and respond normally. What's more, the web browser wouldn't issue an SSL alert, because the SSL cert would match the fake "paypal.com".

rot 13
Gur frpbaq yrggre vf gur ebzna "n".

It's similar to the claims that international support in mozilla was a vulnerability. It isn't. the USER is the vulnerabitlity, educate the user and the vast majority of these problems will go away.

While I agree with you to some extent, you picked a really poor example there. The international characters in the URL toolbar are really very deceptive. Allow me to offer you two picture links.

Letter "a"
Letter "a"

Now you tell me which one is the cyrillic character, and which is the roman character. I don't know about you but my eyes are not that good! It would be trivial for some one to mask their domain in a link as another domain, provided the spoofed domain has a roman letter "a" in it anywhere. You could even set up a proxy server to listen for connections to something like https://paypal.com and respond normally. What's more, the web browser wouldn't issue an SSL alert, because the SSL cert would match the fake "paypal.com".

rot 13
Gur frpbaq yrggre vf gur ebzna "n".

It isn't IDN that's broken, it's users who don't read carefully before clicking a button.

It isn't IDN that's broken, it's users who don't read carefully before clicking a button.