Chris's Wiki :: blog/spam/WindowsManyExecutables

The irritatingly many executable formats of Windows

July 23, 2018

It's impressive how many different executable file formats Windows has.

(I care because our email system wants to reject top-level attachments that are Windows 'executables' and boy is the list getting long.)

I put 'executables' into quotes in this tweet because many of these file formats (or more exactly file types) are not binaries; instead they're text files that Windows will feed to various things that will interpret them in ways that you don't want. Typical extensions that we see as top level attachments (and reject at SMTP time) include .lnk, .js, .bat, .com, .exe, .vbs, and .vbe. Some of these are encoded binaries, while others are text.

We mostly do this checking and rejection based on MIME file extensions, partly because it's easiest. Also, for the ones that are text (and at least some of the ones that are encoded binaries), my understanding is that what makes them dangerous on a Windows machine is their file extension. A suitable text file with the extension ".txt" will be opened harmlessly in some editor, while the same file with the extension ".js" will generally be run if you try to open it.

(We do some file content sniffing to look for and reject unlabeled Windows executables, ie things which libmagic will report as type 'application/x-dosexec'. As you can see here, there are actually a lot of (sub)formats that map to this.)

We've historically added extensions one at a time as we run into them, usually when our commercial anti-spam system rejects one of them as being a virus (this time, several .pif files being rejected as 'W32/Mytob-C'). Possibly this is the wrong approach and we should find a master list somewhere to get almost all of this over with at once (perhaps starting from GMail's list of blocked file types). On the other hand, there's some benefit to passing up rejections, especially if you don't actually seem to need them. If we never see file types, well, why block them?

(I'm not completely convinced by this logic, by the way. But I'm lazy and also very aware that I could spend all my time building intricate anti-spam precautions of dubious actual benefit.)

Comments on this page:

By skeeto at 2018-07-23 06:35:12:

It's a serious Windows design flaw the file execute permission bit is derived solely from its file extension. In practice, file names are under control of the person sending the file (email attachment, browser download, etc), and so that person gets to determine the execution bit of the file.

By Aneurin Price at 2018-07-23 09:08:40:

It's a serious Windows design flaw the file execute permission bit is derived solely from its file extension

That is not correct; in fact, the execute bit is not derived from its file extension at all.

By default in Windows, the execute bit is typically turned on for every directory, with the default inheritance setting being for folders and files to inherit that permission, thus in practice new files will always have the execute bit enabled.

When you double-click (or equivalent) a file with the execute bit enabled, Windows will then use the file extension to determine what to do with it.

If you don't want downloaded files to be executable by default, change the permissions on your downloads folder to make its children non-executable by default, so you have to turn it on manually on a case-by-case basis. Many organisations will do this sort of thing for their users as part of their standard setup, perhaps going so far as to prevent execution from any user-writable directories, but by default Windows doesn't do this as it's a nightmare for non-technical users.

In summary, the design for how this works in Windows is identical to how it works in Linux, but there are two differences in policy: 1) files are executable by default, and 2) when attempting to execute a file, Linux does so by inspecting the file's contents (typically the first few bytes), whereas Windows does so by looking at the file extension. I think this was a bad choice and I don't find the rationale for it at all convincing versus the downsides, but it's not completely mad.

[For the sake of completeness: Actually I simplified a bit. Windows does also have some other supporting machinery that tags files with some metadata indicating where they came from and the source's associated 'trust' level, so in practice a file downloaded from the web or email or some random network location won't just be directly executable even when its executable bit is set. Instead, files not from a trusted source will by default prompt the user before being run. I believe this is governed by a system policy that could be set to prevent execution entirely without giving the option to go ahead, but I've never looked into that.]

Written on 23 July 2018.

«	The problem with some non-HiDPI aware applications (is that they're very small)

Some notes on lifting Python 2 code into Python 3 code