Can we believe our eyes?

Someone sent me this link, those pesky trojan writers are gettin' sneakier!

http://blogs.technet.com/b/mmpc/archive/2011/08/10/can-we-believe-our-eyes.aspx

1. Goto Tools | Folder Options...|View
2. Select "Show hidden files, folders, and drives"
3. Uncheck "Hide extensions for known file types"

@cbae: That is because most people are too stupid to understand the concept of a file extension.  If you ask my mom what a file extension is she probably couldn't give you an answer.  It is sometimes hard to remember that what comes easy for tech people is not so easy for the average person.

12 minutes ago,JeremyJ wrote

@cbae: That is because most people are too stupid to understand the concept of a file extension.  If you ask my mom what a file extension is she probably couldn't give you an answer.  It is sometimes hard to remember that what comes easy for tech people is not so easy for the average person.

I think Windows should surround the icons for executables (outside of Details view) with a noticeable thick border or background (that exists outside the icon area, so icons cannot mimic the look) so you can see if a file at a glance if a file is a program or not.

I think this is do-able, the current ListView control in Windows supports hover backgrounds, I propose a patterned background be permanently visible for all executable file types.

Did anyone read the linked article? What possible benefit would showing extensions or putting ugly borders around executables do to help?

Abusing the fact that Unicode has characters that look alike, but are different is becoming an increasingly common attack vector. I'm not sure there's an easy solution to it either, short of breaking the display of Unicode filenames.

@AndyC: The border around the executable would've helped with the gpj.exe RLO thing. A border is maybe not a good example, but visually distinguishing executable files in a way that icons can't mimic wouldn't be a bad thing (it could be a different colour or something, we already have blue for compressed folders). Of course, in details view you can already spot the different if you look at the Type column, but that isn't always available.

The character similarity, I'm not sure what could be done about that, if anything.

Why would I get virus when viewing a jpg using a Photo Gallery?

I thought of a couple of things, but there's too many holes. You could artificially limit the naming of system files to a specific locale, such as the one that Windows was installed under. However, that might cause problems for people, such as Sven, who need to work across languages.

One that might help in the scenario mentioned in the technet post is to completely disable the options to hide system files, and file extensions, and not respect the hidden attribute for system folders such as Program Files and Windows. Generally I want to see everything when I go into those folders. Nothing should be hidden.

@magicalclick: Because the file isn't really a jpg. I could write virus.exe, and for the icon, embed the default Windows icon for jpgs, and then change it's name to annakournikova.jpg.exe. Then if you see that on a system that hides extensions, you'll see a jpg icon labelled annakournikova.jpg.

People don't open a photo gallery and browse to a file they downloaded, they immediately double click and get themselves into trouble.

10 minutes ago,AndyC wrote

Did anyone read the linked article? What possible benefit would showing extensions or putting ugly borders around executables do to help?

Abusing the fact that Unicode has characters that look alike, but are different is becoming an increasingly common attack vector. I'm not sure there's an easy solution to it either, short of breaking the display of Unicode filenames.

The exploit to copy a fake version of the hosts file to the etc folder requires that the real one be hidden and the fake one have the Unicode name. If you're even smart enough to suspect that there's something amiss about the hosts file and decide to check the etc folder, then you'd be smart enough to notice that two files with the same name in the same folder (with one of them grayed out to indicate that its hidden) is a little bit peculiar. The "cleverness" of this exploit depends on files being flagged as hidden are actually hidden.

As for RLO exploit, I'm not exactly sure how the file name would render if the extensions were hidden ("picjpg"?), but a file with the letters "exe" ANYWHERE in the name just screams "Click me! I'm not an exploit. Honest!"

1 hour ago,kettch wrote

I thought of a couple of things, but there's too many holes. You could artificially limit the naming of system files to a specific locale, such as the one that Windows was installed under. However, that might cause problems for people, such as Sven, who need to work across languages.

Color file names that are not in the system's current locale? I don't use encryption, but I know that the file names for encrypted docs are in blue.

EDIT: Actually, that only solves discovery.

@kettch:

ah, you mean that? Yeah, it is easy to fix by showing extensions. But, even if you run the exe, the WinXP or later will always tell me it is an exe and I have to click OK as well. If I cannot see the photo right away, it is very easy to know something is out of ordinary.

@magicalclick: That only works if the exe was downloaded, and still has those attributes.

2 hours ago,MasterPie wrote

*snip*

Color file names that are not in the system's current locale? I don't use encryption, but I know that the file names for encrypted docs are in blue.

EDIT: Actually, that only solves discovery.

Encrypted files are green, Compressed files are blue.

But yeah, your proposal works too, however the colour would have to be purple because colour-blind people wouldn't be able to see red (from green), and there's insufficient contrast for yellow.

2 hours ago,kettch wrote

@magicalclick: That only works if the exe was downloaded, and still has those attributes.

I overlooked that. Thanks. That indeed is a problem.

This is what we call "epic win" where I am from.

It wasn't so much the simple "fake" extension that's of concern, it's the latter part of the article that spoofs the hosts file for instance, using seemingly identical unicode chars.

@jh71283: That's the much harder problem to solve. I sent a message to Michael Kaplan who works on unicode and localization support in Windows to see if he knows a way to counter that without breaking stuff.