Windows 7 Users Warned Over Filename Security Risk 613
nandemoari writes "Would-be Windows 7 users have been warned to change a default setting which could leave them vulnerable to attack via bogus files. As a result, Microsoft is taking flak for failing to correct a problem found in previous editions of Windows.
The issue involves the way Windows Explorer displays filenames.
In all editions of Windows after Windows 98, the default setting hides the filename extension (which identifies what type of file it is). This means that a Word file titled 'partyinvite.doc' will show up in Windows Explorer as simply 'partyinvite'. The only exception to this rule is if Windows does not recognize the file type.
The reason for this setting is that it makes for a less cluttered look and avoids filling the screen with redundant detail. However, a flaw in the way it works leaves it liable to exploitation by hackers. They can take an executable file (which can do much more damage to a computer when opened) and disguise it by calling it 'partyinvite.doc.exe.'"
This has been around for a long time. (Score:1, Informative)
Second, the default view for most folders in 7 is the details view, which means whether a file is an executable will be exposed to the viewer by default regardless of whether extensions are hidden.
By all means, edit this setting if you must, but realize that 7 has already taken a good number of steps to deal with the danger.
Not new, not unique to Windows (Score:5, Informative)
OSX hides extensions, too, and what's arguably worse, OSX allows you to arbitrarily replace the icon of any file, thereby allowing you to disguise files more easily. Don't some Linux DEs do the same thing?
It's sort of unfortunate that we rely on filename extensions to identify file type at all. Users have a tendency to accidentally remove extensions when they're renaming if you don't hide them. But then if you hide them, then users are missing the single most important cue as to what file-type a file is.
Re:This has been around for a long time. (Score:2, Informative)
UAC doesn't really come that much into play here. It's still possible to capture all your credit card data without elevating to admin.
That said, Explorer blocks execution of files downloaded from the Internet, and Outlook blocks executable attachments completely.
Re:This has been around for a long time. (Score:3, Informative)
Here's the thing: UAC is one layer of defense against this (even though UAC is never called a protective layer, it seems). If there is no verified publisher, UAC will say that the publisher is unknown and thus, in theory, it should trigger a red flag with people. That's how all of my computer illiterate friends approach it, and they've never had problems.
Heck, just about all legitimate programs I download from a non-major publisher says that the publisher is unknown. About the only programs that I have installed with a "known" publisher are Firefox, and iTunes. The rest still say unknown publisher.
Re:How can this be? (Score:5, Informative)
This is something I have instantly turned off in every version of Windows so far. Thank god for nLite [nliteos.com] - you can create your install disk with all this bs turned off to start with!
Similar with OS X (Score:4, Informative)
As an Apple fan-boy, I am chagrined to have to point out that there is an analogue of this problem on OS X. Meta information about a file will contain information about its "Creator" (which is often used to determine what application it should be opened with) and also the file Icon.
This allows for a file to have, say a plain text icon but open as something else altogether. Apple has taken some mitigating steps (warnings before executing downloaded files for the first time), but has not changed the underlying problem which stems from concealing information from the user.
Re:Not new, not unique to Windows (Score:4, Informative)
Vista (and 7) decrease the likelihood of accidental file extension deletion by highlighting only the filename (sans extension) when renaming files through explorer. Personally, I'm usually renaming the extension, or adding ".old".
BULLSHIT FUD (Score:3, Informative)
Run virus.exe in XP (SP2), Vista, or (I presume) 7.
What's that box? A security warning about unsigned code?
Rename the file to virus.txt.exe and try again.
What's that box? A security warning about unsigned code?
Fuck off insecurity experts.
Re:How to rename files (Score:5, Informative)
The Vista file manager does that too.
Re:Not really news, and a non-issue (Score:3, Informative)
You mean it's just like in Windows?
Re:kill the filename.extension paradigm (Score:4, Informative)
The filename should not contain any metadata. The date is not included in the filename, so why is the filetype in there?
No metadata in the filename? But isn't the filename metadata in itself? By giving the file a name -- a description of the content -- I provide some metadata that lets me know what the file contains. I don't think it is all that stupid to have a convention for file naming.
The MacOS X approach (Score:5, Informative)
Upon reading this, I wondered whether MacOS X suffered the same issue, so I decided to test. I disabled the showing of all extensions (Finder preferences), duplicated Text Edit, so it appeared as "TextEdit 2" and then edited the visible name to "TextEdit 2.doc". The result was displaying itself as "TextEdit 2.doc.app". For other file types, such as a PDF doing the same thing results in being asked if you are sure you want to change the filename extension, though renaming from the Terminal a PDF from "toto.pdf" to "toto.doc.pdf" resulted in the same visual behaviour as the one observed for the application. Its an interesting solution to the problem, since basically if the file has multiple extensions they are all shown.
The issue described in the post has already caused me issues in the past on Windows XP, on a developer's machine, where extensions were not shown by default. Imagine an Apache conf folder that contains:
http.conf
http.conf.bak
The first one appears as 'http' and the second one as 'httpd.conf'. I didn't hit me straight away that the wrong file was being edited.
Does anyone know how Linux handles this in the various GUI file managers?
Re:How can this be? sufixication (Score:5, Informative)
> Metadata sufficient to render file extensions obsolete would leave us with http://example.com/file [example.com], with no way to tell what it contains.
That's where MIME types come in to save you. While it is true that from the URL you can't tell the contents, the moment you do a "GET /file" the server will tell you the mime type (e.g. application/msword), and you can save that information in the file's meta data on your local filesystem (e.g. save it as file.doc).
Re:Not new, not unique to Windows (Score:1, Informative)
Linux DEs are not identifying files by their exceptions but by their MIME type. That is, they call libmagic, or something else to determine what is actually inside the file in question and will fall back to extension only if they have no other choice.
Furthermore Unix executables (this applies to both Linux and Mac OSX) need to be given permission to be executed and it is not set by default. Therefore user has to manually do "chmod a+x evilworm" or equivalent in order to fry his computer.
That said I wonder what the attack vectors would be like if Linux gained popularity.
Reminds me of... (Score:3, Informative)
...another Windows bug I ran into the other day with how the IE engine deals with URLs.
Given the following URL (with the server properly responding with mime-type of octet-stream and an otherwise proper response):
... IE decides that since it doesn't know what a ".exe?query=string" extension is, so it strips the "extension off" and tries to connect to:
... which (in my case) doesn't exist.
http://www.somedomain.com/url/path/to/file.exe?query=string [somedomain.com]
http://www.somedomain.com/url/path/to/file [somedomain.com]
This is another example of why injecting proprietary meaning, which often contradicts with more fundamental established protocols, into processes/protocols is problematic.
Re:How can this be? (Score:3, Informative)
PIF files (Score:5, Informative)
F-Secure points out [f-secure.com] that .PIF files will have their extension hidden even if you change the display option.
Re:How can this be? (Score:3, Informative)
I'll assume that you're being sarcastic, but just in case you're not...
No, normal users do not use Windows Explorer to open documents they're normally working on. They tend to go to the application that created the file (like Word or Access) and quickly get to it from that app's Recently Used Documents. And if it's not there, they use that app's File | Open, which only shows filetyes registered to that program.
It's more effecient than the way you're suggesting.
The only time Windows Explorer is commonly used (by normal users) is when they need to manage a bunch of files of different types, or move/copy/delete stuff around. And most users don't even touch that stuff.
As for folder structure, most users are doing that from within the application too, not Windows Explorer.
As for starting applications, no one does that but your most hard-core geeks. That's what the Start Menu is for.
I used to turn on the file extensions when I got a new install, but after a while I stopped doing it. After all, there is a whole column called "Type" which proudly shows you the filetype should you be curious. And, you can sort by that column (and in Vista, you can filter, too).
Let's face it, most people don't need to see the extension. They don't even need to know what kind of file it is. They double-click and Windows opens the right app.
Re:How can this be? sufixication (Score:5, Informative)
By reading the MIME type stored in filesystem metadata! In this example, when you save a document in Microsoft Word and name it "file", instead of appending a ".doc" extension to the filename, Word would leave the filename alone and add a MIME type. The OS's file browser would use this MIME type to determine which application to open the file in when double-clicked (instead of using extensions the way it does now), and a web server would read the MIME type and send that to the browser, instead of looking up a file extension in a table the way it does now.
For backwards compatibility, users could choose to append an extension to the filename, but this would be completely ignored by newer operating systems. If you chose to name your Word document "file.jpg", you could, and your OS wouldn't care, but since this would cause significant confusion when sending it to users of legacy systems, you wouldn't do that.
The Macintosh filesystem (MFS/HFS/HFS+) used 32-bit "type" and "creator" codes, normally rendered as a 4-character string. This was a good idea in 1984, but not nearly as specific as MIME types (on classic Mac OS, HTML and XHTML and CSS and JavaScript files would all have their "type" field set to "TEXT"). MIME types are definitely the way to go, if you want to construct something like this today.
Re:kill the filename.extension paradigm (Score:2, Informative)