Everything you download already comes with the mark of the web, which stops most simple exploitation in its tracks. That's why malware distribution has to go through annoying side steps like attacker controlled SMB servers over the internet to spread executable files.
Also, Windows ACLs come with an execute permission per user, group, or any other policy related object. It's enabled by default for executable files you're allowed to read, but there's absolutely nothing stopping you from making executables unexecutable.
Furthermore, just about every executable file gets a massive "you're about to infect your computer, kill your pets and sacrifice your children to Satan" prompt by default. You can disable it, but it's enabled in almost every other case.
That's why attackers leverage the side effects of fringe cases, like RTF OLE embeddings and CHM/MHT wrappers.
Half the steps in this graph would work for macOS or Linux as well if they're set up for corporate environments. Most of it is browsers and office applications just doing their thing. Notice how none of these include code actually executable in an operating context until the very end, when the very last sandbox has been escaped and a script downloads the actual payload from a position where it would be able to set the executable bit anyway.
> Half the steps in this graph would work for macOS or Linux as well if they're set up for corporate environments. Most of it is browsers and office applications just doing their thing. Notice how none of these include code actually executable in an operating context until the very end, when the very last sandbox has been escaped and a script downloads the actual payload from a position where it would be able to set the executable bit anyway.
Yes indeed, but this logical and thought out explanation is no match for a limited-characters hot take (plus an image!) on Twitter. That's "information" now.
> Also, Windows ACLs come with an execute permission per user, group, or any other policy related object. It's enabled by default for executable files you're allowed to read, but there's absolutely nothing stopping you from making executables unexecutable.
That's the whole point that GP is raising: whether the execute bit is set by default, or not.
However personally I think the file itself should carry the information that it is meant to be executable (e.g. through a magic like shebang, an ELF/PE header, file extension, etc). Under UNIX-like OS's, it just creates pointless friction for users who are already certain that they do want to run the executable they just downloaded.
Quarantine is (at least conceptually) a better and more general mechanism than the execute permission, as files other than executables could also be considered dangerous (like an image file trying to pwn the decoder, or a local HTML file trying to access the network). The quarantine bit could tell the OS and/or application to highly distrust the content (e.g. run it in a sandbox that denies FS/network access).
Also, Windows ACLs come with an execute permission per user, group, or any other policy related object. It's enabled by default for executable files you're allowed to read, but there's absolutely nothing stopping you from making executables unexecutable.
Furthermore, just about every executable file gets a massive "you're about to infect your computer, kill your pets and sacrifice your children to Satan" prompt by default. You can disable it, but it's enabled in almost every other case.
That's why attackers leverage the side effects of fringe cases, like RTF OLE embeddings and CHM/MHT wrappers.
Half the steps in this graph would work for macOS or Linux as well if they're set up for corporate environments. Most of it is browsers and office applications just doing their thing. Notice how none of these include code actually executable in an operating context until the very end, when the very last sandbox has been escaped and a script downloads the actual payload from a position where it would be able to set the executable bit anyway.