Windows 10's 'Controlled Folder Access' Anti-Ransomware Feature Is Now Live (bleepingcomputer.com)

A reader shares a BleepingComputer report: With the release of Windows 10 Fall Creators Update last week, the "Controlled Folder Access" that Microsoft touted in June is now live for millions of users. As the name hints, the Controlled Folder Access feature allows users to control who can access certain folders. The feature works on a "block everything by default" philosophy, which means that on a theoretical level, it would be able to prevent ransomware when it tries to access and encrypt files stored in those folders. The benefits of using Controlled Folder Access for your home and work computers are tangible for anyone that's fearful of losing crucial files to a ransomware infection.

Comments

First Exploit

[Calydor]

First exploit will take that feature, lock out USER from doing anything, and pop up a ransomware screen.

Not sure...

[djbckr]

How does this work? If "you" somehow allow access to the ransom-ware by clicking something you shouldn't, and the folder is owned by "you" - does this help? And if you are being asked for access to something "you" own on a regular basis, does this actually work?

simple, decade old solution

[Anonymous Coward]

On VMS you could never overwrite a file. File system would by default always keep all the previous versions of it. Ransomware action like that would just result in having additional, encrypted, versions of your files.

Re:Um... Isn't this just default Linux permissions

[Lobachevsky]

No, it's not the same. Windows already has proper permissions for user directories since Windows NT. The issue is that ransomware runs under the same uid as yourself, so if you can access your own file, then the ransomware program can access those same files. This new feature makes it so that even if the uid has access, you can specify ADDITIONAL restrictions, like which exe is permitted to do so. So some ransomware.exe, even with your uid, will be unable to make changes.

There is no such ability in Linux or *nix, since ACLs are solely based on uid and not the name of the executable with your uid. The closest might be a sudoers file with specific commands for which you're allowed to escalate to root privilege. A *nix ransomware program running with your uid has the exact same privileges as bash or kde or gnome running with your uid and access to all your files.

All that said, there are still ways to circumvent privileges restricting which execs are allowed to access the folder/directory. For instance, if chrome.exe is given access, then any ransomware running as a chrome app will appear to be chrome.exe from Windows' perspective and be given access. This problem exists for any exec that allows running scripts or remote code, like bash or the Windows-equivalent powershell. You either have to deny all powershell execs from access, or grant all powershell execs access. The safest approach would be to not get infected with rogue code with your uid privilege. And if you get infected with rogue code that has Administrator (root) privileges, you're hosed because it can bypass or remove these restrictions altogether.

Re:Um... Isn't this just default Linux permissions

[gillbates]

So the issue now becomes a question of how ransomware authors write ransomware in something like Flash or Chrome, which the average user would always enable. It seems like they haven't fixed the fundamental, underlying problem of users running untrusted code, but only moved the goalposts.

The underlying issue here is that security holes of this type are enabled by Windows:

1. Users don't know, and can't reasonably be expected to know, the difference between executable code and data because the OS blurs the distinction. How many times have we heard Windows users say, "I saved it in Word", or "I saved it in Chrome"?
2. Windows obscures the internals from the users, which makes it even more difficult for users to understand which programs are running. A user has no way of saying to Windows, "These are the programs I might run - don't start any executable I haven't given permission." By default, the bash shell won't execute any executable except those in special directories (i.e., the PATH), and marked as executable. By default, Windows will execute any executable it can find on the filesystem. This simple step would stop a lot of ransomware.
3. The fundamental problem of allowing untrusted code execution by default is that it has spawned an entire class of web software which requires script execution to function correctly. Yes, you and I might be aghast at this, but for the Windows world, running untrusted software is part and parcel of the web experience. Windows has taught them to think there's something "wrong" with their computer if JavaScript is disabled.

The irony of this is that the NTFS filesystem has had fine-grained permissions for 2 decades, but Windows never exploited it until now, and even this move - while better than nothing - is questionable. Why does Microsoft always get the usage model wrong?