5 ms·

The single largest outstanding security problem with Windows is the one-two punch combo of hiding file extensions by default + not having an executable bit. Thi

by donatj 3y ago

The single largest outstanding security problem with Windows is the one-two punch combo of hiding file extensions by default + not having an executable bit. This makes it insanely easy for an attacker to simply create a malicious executable that has the icon of a word document or other recognizable type. There is literally no way for a lay person to detect the danger there. If there were an executable bit, exe’s from strange places wouldn’t just run without being granted permission. If extensions were visible by default, the very slightly savvy could SEE the danger. The combo lack-thereof is the danger. With how many notifications Windows gives you already, it really seems like at the very least just warning you when you double click something the first time “this is an executable, use caution” would go a long way. Binaries downloaded from browsers get stapled with a “potentially unsafe” extended attribute that pops a warning the first time you try to open it. This helps but is backwards. It should go the other direction and every binary should warn you until stapled with a “user has acknowledged the danger” attribute.

FireInsight 3y ago
A common technique is exploiting macros in real word documents, which would still work with the added protection of an executable bit and being able to see file extensions.
- nicce 3y ago
  There is protection and that is why macros are mainly used. https://learn.microsoft.com/en-us/windows/security/operating-system-security/virus-and-threat-protection/microsoft-defender-smartscreen/ https://learn.microsoft.com/en-us/windows/security/operating...
- ectospheno 3y ago
  No human would assume he was providing a solution to every attack. Not doing something because it doesn’t solve every problem is a great way to never fix anything. Not brushing your teeth because you ran out of dental floss is dumb.
nicce 3y ago
> If there were an executable bit, exe’s from strange places wouldn’t just run without being granted permission. If extensions were visible by default, the very slightly savvy could SEE the danger. The combo lack-thereof is the danger. By default Windows does not run anything which does not have valid signature, unless you give the permission. Maybe you have disabled this feature? Many do it, because it is annoying, as you need to give permission almost for anything you download from the internet.
- nullindividual 3y ago
  Windows prompts if it doesn't have a signature, but will allow you to run it directly from the prompt, unless it involves a driver, which must be signed without using bcdedit to bypass that feature.
  - nicce 3y ago
    That does not fit the usecase when someone clicks executable with Word icon. And how it is different than asking permission to run it? Edit: as prompt I thought command-line
    - mrguyorama 3y ago
      And like all hard problems, that cannot be solved by technology. "Users will literally run the icon that's called malware" has nothing to do with Windows being written in not-Rust, and won't be solved by an operating system written in Rust. You cannot simultaneously empower the user to do useful things and prevent the user from using that exact power to fuck themselves. It's no different from trying to build a gun that can only shoot criminals. It's a completely invalid goal.
  - jeroenhd 3y ago
    Exactly, Windows is asking for permission to execute the executable file. Actually, in its default configuration, it's telling you it has blocked a dangerous file from opening (but you can click a tiny link to show a second button to allow executing the file anyway).
nullindividual 3y ago
> If there were an executable bit, exe’s from strange places wouldn’t just run without being granted permission. If the file is downloaded with IE/Edge and comes from the Internet zone, there is an ADS written (Zone.Identifier) which flags the executable to prevent it from being executed. The user needs to manually unblock the file.
- cobbal 3y ago
  Firefox too, and they show up as annoying extra files with weird unicode names if you download directly to a WSL drive.
  - nullindividual 3y ago
    Which makes sense as this is an NTFS Alternate Data Stream; so much like the resource forks of MacOS Classic, you'll see ADS files as separate on file systems which don't understand the structure.
gochi 3y ago
Windows does what you're suggesting on several layers. Default browser warns about downloads before downloaded, smartscreen prompts about running unverified apps, and UAC prompts a final time.
jeroenhd 3y ago
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.
- rollcat 3y ago
  > 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).
- thefz 3y ago
  > 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.
emptyfile 3y ago
[dead]
tracker1 3y ago
Worth noting, if you use NTFS, there is an executable bit. In fact in many places, user profiles are set to disallow execution altogether.
- mr_mitm 3y ago
  And then Microsoft in all its wisdom decides to place one of the most widely used pieces of software, Teams, inside the user profile.
  - sixothree 3y ago
    I'm not understanding why the practice of installing applications inside of my user profile is an acceptable practice to the point where it is actually common.
    - drbawb 3y ago
      As far as I'm aware it's mostly a hack to avoid UAC elevation. If your goal is to get Chrome onto as many computers as possible: you have to be able to install without admin privs. (Also, even if the user can elevate themselves, I imagine the conversion rate is marginally better if you can avoid the "scary" UAC prompt. The conversion rate is definitely better if an unprivileged user can avoid invoking the wrath of their IT admins/policy.)
      - sixothree 3y ago
        Right. I just feel like the opposite direction is where we want to be. I don't understand in what world is it acceptable to install applications without the user's (or operating system's) permission? This is literally a side channel installation of software. As much as I hate the store concept, I would prefer everything be handled via a store than this mess.
        jsmith45 3y ago
        Installing per user was an MSI feature that I'm pretty sure predates UAC. The idea was not about installing without user's permission, but was entirely about allowing normal (non-admin) users to be able to install software, which would obviously be limited to their account only. This means it needs to install to part of the filesystem where a non-admin user has write permissions. There are only two possible places. The user's profile, or the Programdata folder. Installing to the latter would have problems where one user could maliciously modify a program another installed (or issues if two users installed different versions of the same program), so the user's own profile is where it must go. This concept is nothing new, users could long compile and install software into their home directories on unix platforms.
GordonS 3y ago
Totally with you on hiding file extensions - why they made that the default is beyond me.
- tracker1 3y ago
  Compared to Linux that doesn't use file extensions at all to mark executables?
- mrguyorama 3y ago
  It doesn't matter if they showed extensions by default, because users still download and run nude-photo.jpg.exe
nullindividual 3y ago
> file extensions by default File extensions aren't necessarily mandatory in Windows as long as the Magic Number is recognized by Windows (Word documents, for example).

by donatj 3y ago

FireInsight 3y ago

A common technique is exploiting macros in real word documents, which would still work with the added protection of an executable bit and being able to see file extensions.

nicce 3y ago
There is protection and that is why macros are mainly used. https://learn.microsoft.com/en-us/windows/security/operating-system-security/virus-and-threat-protection/microsoft-defender-smartscreen/ https://learn.microsoft.com/en-us/windows/security/operating...
ectospheno 3y ago
No human would assume he was providing a solution to every attack. Not doing something because it doesn’t solve every problem is a great way to never fix anything. Not brushing your teeth because you ran out of dental floss is dumb.

nicce 3y ago

> If there were an executable bit, exe’s from strange places wouldn’t just run without being granted permission. If extensions were visible by default, the very slightly savvy could SEE the danger. The combo lack-thereof is the danger. By default Windows does not run anything which does not have valid signature, unless you give the permission. Maybe you have disabled this feature? Many do it, because it is annoying, as you need to give permission almost for anything you download from the internet.

nullindividual 3y ago
Windows prompts if it doesn't have a signature, but will allow you to run it directly from the prompt, unless it involves a driver, which must be signed without using bcdedit to bypass that feature.
- nicce 3y ago
  That does not fit the usecase when someone clicks executable with Word icon. And how it is different than asking permission to run it? Edit: as prompt I thought command-line
  - mrguyorama 3y ago
    And like all hard problems, that cannot be solved by technology. "Users will literally run the icon that's called malware" has nothing to do with Windows being written in not-Rust, and won't be solved by an operating system written in Rust. You cannot simultaneously empower the user to do useful things and prevent the user from using that exact power to fuck themselves. It's no different from trying to build a gun that can only shoot criminals. It's a completely invalid goal.
- jeroenhd 3y ago
  Exactly, Windows is asking for permission to execute the executable file. Actually, in its default configuration, it's telling you it has blocked a dangerous file from opening (but you can click a tiny link to show a second button to allow executing the file anyway).

nullindividual 3y ago

> If there were an executable bit, exe’s from strange places wouldn’t just run without being granted permission. If the file is downloaded with IE/Edge and comes from the Internet zone, there is an ADS written (Zone.Identifier) which flags the executable to prevent it from being executed. The user needs to manually unblock the file.

cobbal 3y ago
Firefox too, and they show up as annoying extra files with weird unicode names if you download directly to a WSL drive.
- nullindividual 3y ago
  Which makes sense as this is an NTFS Alternate Data Stream; so much like the resource forks of MacOS Classic, you'll see ADS files as separate on file systems which don't understand the structure.

gochi 3y ago

Windows does what you're suggesting on several layers. Default browser warns about downloads before downloaded, smartscreen prompts about running unverified apps, and UAC prompts a final time.

jeroenhd 3y ago

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.

rollcat 3y ago
> 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).
thefz 3y ago
> 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.

emptyfile 3y ago

[dead]

tracker1 3y ago

Worth noting, if you use NTFS, there is an executable bit. In fact in many places, user profiles are set to disallow execution altogether.

mr_mitm 3y ago
And then Microsoft in all its wisdom decides to place one of the most widely used pieces of software, Teams, inside the user profile.
- sixothree 3y ago
  I'm not understanding why the practice of installing applications inside of my user profile is an acceptable practice to the point where it is actually common.
  - drbawb 3y ago
    As far as I'm aware it's mostly a hack to avoid UAC elevation. If your goal is to get Chrome onto as many computers as possible: you have to be able to install without admin privs. (Also, even if the user can elevate themselves, I imagine the conversion rate is marginally better if you can avoid the "scary" UAC prompt. The conversion rate is definitely better if an unprivileged user can avoid invoking the wrath of their IT admins/policy.)
    - sixothree 3y ago
      Right. I just feel like the opposite direction is where we want to be. I don't understand in what world is it acceptable to install applications without the user's (or operating system's) permission? This is literally a side channel installation of software. As much as I hate the store concept, I would prefer everything be handled via a store than this mess.
      - jsmith45 3y ago
        Installing per user was an MSI feature that I'm pretty sure predates UAC. The idea was not about installing without user's permission, but was entirely about allowing normal (non-admin) users to be able to install software, which would obviously be limited to their account only. This means it needs to install to part of the filesystem where a non-admin user has write permissions. There are only two possible places. The user's profile, or the Programdata folder. Installing to the latter would have problems where one user could maliciously modify a program another installed (or issues if two users installed different versions of the same program), so the user's own profile is where it must go. This concept is nothing new, users could long compile and install software into their home directories on unix platforms.

GordonS 3y ago

Totally with you on hiding file extensions - why they made that the default is beyond me.

tracker1 3y ago
Compared to Linux that doesn't use file extensions at all to mark executables?
mrguyorama 3y ago
It doesn't matter if they showed extensions by default, because users still download and run nude-photo.jpg.exe

nullindividual 3y ago

> file extensions by default File extensions aren't necessarily mandatory in Windows as long as the Magic Number is recognized by Windows (Word documents, for example).