Hacker News new | ask | show | jobs
by donatj 1255 days ago
Hear me out, the biggest most fundamental flaw with Windows security is the lack of an executable bit combined with icons being embedded in the executable. Making it even worse, Windows hides file extensions by default.

Executability being based entirely on filename makes it way too easy to create a .exe with the icon of a familiar file type like a Word Document. Then and unsuspecting layman who has no way of knowing it's an executable because the file extension is hidden sees no reason not to open it.

This is much less of a probably in Unix based operating systems because permissions needed for executability don't come with raw files over the network or through email, unlike extensions. Moreover icons aren't embedded in binaries, and depending on your environment, you're probably shown the file extension.

4 comments

> create a .exe with the icon of a familiar file type like a Word Document

But this kind of confusion attack is not really used anymore.

Now it's about convincing the user to intentionally run a binary. If the user wants to run a binary, they will do it, regardless if it means double-clicking an .exe or typing "curl | sh" in the terminal.

Windows really ought to just hash every executable file, and then whitelist good files.

Perhaps 1 million exe files are in widespread use in the world. Anything that isn't on that list, I don't want running on my corporate network.

Compilers that make an exe file can have some new windows API that says "I just compiled this file, so it's fine to run".

> Perhaps 1 million exe files are in widespread use in the world.

They already do that. It's called SmartScreen.

> Compilers that make an exe file can have some new windows API that says "I just compiled this file, so it's fine to run".

I don't think you thought this through. Because then malware will either call that new API, or ship with their own compiler.

> Because then malware will either call that new API,

As soon as malware is running, you have already lost.

This is for when the user has downloaded TotallyNotAVirus.exe from a dodgy website and tries to double click it.

> the lack of an executable bit

NTFS does support an execute bit (Traverse Folder / Execute File). For some reason, it's just not used in any way that would provide a security benefit by default, instead basically just being set on everything.

A related odd quirk I ran into once: if you use an Amazon S3 Storage Gateway as an SMB share, the Execute File permission suddenly matters. I don't fully understand why, but Windows won't run an .EXE file off the share without setting that security bit. It caused us quite a bit of pain. Normally it doesn't matter at all.
Different subsystems, layers and libraries in Windows do have different interpretations of what characters to allow in a filename, what permission bits to obey, how to behave on different filesystems, etc. It's a huge mess. You can e.g. create invisible, undeleteable files by using characters the explorer doesn't like.
What's funny is when the Mac guy names a file on a network share that nobody else in the office can access or rename.
I think Windows has some kind of source flag, where if it’s from an online source, you have to opt-in into running it.
zone.identifier aka "Mark of the Web" and it is responsible for triggering a Smartscreen scan of that file.

You get an 'are you sure you want to run this' and also the Office Protected View, both of which users will reflexively click via muscle memory at this point.

You also get the download and referrer URL attached to every file that came from the internet which is nice for forensics stuff.

It's a filesystem fork on the file triggering a UAC style warning. Laypeople are imho generally pretty blasé about accepting those.
People have been trained to ignore such popup warnings by common superfluous popup warnings like "are you sure you want to quit?", and nowadays ads and newsletter sign up bullshit.
You can set a bit like that on directories in NTFS, and clear/inherit to all child directories. Such as setting it to no-execute for all user directories except those expected to host user instances of applications.