Slashdot Mirror
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.
First exploit will take that feature, lock out USER from doing anything, and pop up a ransomware screen.
-=This sig has nothing to do with my comment. Move along now=-
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?
The new feature is not permission by users but permission by an application running. The virus, most of the time, run under your own credentials.
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.
The file permissions on Windows filesystems are far more granular and not just based on an xxx field of bitmaps like on vintage OSes like Unix.
What I would like to see for the defanging of ransomware is a way to permanently disable filesystem encryption unless it is re-enabled by a very-restricted-access tool, i.e. filesystem encryption can be permanently disabled on a system and re-enabling it requires a local admin account running in Safe Mode to re-enable plus answer a prompt at reboot.
Encryption and similar password-restricted functions hard-coded into a system, i.e. BIOS passwords, are a catch-22. If you don't enable them, you have to leave them sitting there 'open' for some other entity to enable. Why not just leave the encryption libraries not-installed on a system that doesn't want or need them?
The beauty of the 'home directory' structure design of a UNIX system is that if malware, or a faulty application you are coding, attempts to wipe out your filesystem, the only thing it will be able to touch is your personal data, the things you actually use the computer to create and manipulate.
Your /home directory can be wiped, and any databases, etc. that you have permission to manipulate can be corrupted. But the binaries that can be re-installed from a CD-ROM or an NFS share in a matter of minutes with a reinstall of the OS are both vigorously protected and easily replaced.
Only the important bits on the computer are vulnerable. Isn't that how it's supposed to work?
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.
permanently disable filesystem encryption
Just because the Windows libraries are a convenient way to encrypt, they're just the low-hanging fruit. If this became difficult to use, they'd just use another library to encrypt the file contents. Malware can easily include this if needed.
Nope. By the sound of things, this is more akin to the sandboxing feature present in apps sold via the Mac App Store. The apps are running under your permissions, just as they always have, but they now need to request and be granted permission to access new folders. Basically, just as mobile OSes require that an app request and receive permission before it can use the camera, the mic, or your location, Windows is, from what the summary sounds like, now requiring that apps request permission to access specific folders.
ummm the malware out there isn't using OS crypto to do it's thing. Forcing filesystem encryption to require an added permission won't change anything. Likewise these malware executables can easily bring along their own crypto libraries, in fact I think many already do. Denying crypto libraries will also not change anything! You may want to do some research...
So how does this work?
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
Ransomware only goes after your personal data. Documents, pictures. There are not many outside your home directory.
I mean command line tools. Do you have to give permission to everything, like copy.exe?
My opinion would have been a heck of a lot more useful for Microsoft to roll out a versioning file system. That would have provided more value to customers and end up being way more useful in every way vs piling on new access control regimes and expecting people to use it for real this time.
Would be interesting to hear what if anything prevents an attacker from modifying search path environment variables or user registry or CLI parameters to convince software to load custom add-on haxor.dll's and then launch a trusted program. Unlike DLL injection this does not require any elevated privileges. Does the system keep track of all of an applications possible dependencies? If a software program dynamically loads a new DLL in response to user action such as enabling a new feature within the software does Windows flash an alert and ask the user if it's ok? If so what percentage of users are likely to be qualified to even begin to provide a coherent response?
The file permissions on Windows filesystems are far more granular and not just based on an xxx field of bitmaps like on vintage OSes like Unix.
Non-vintage Unix don't rely exclusively on xxx field bitmap neither.
Modern unix filesystems do support ACL for more complex access control.
Modern features like SELinux and AppArmor also help having application-level control.
What I would like to see for the defanging of ransomware is a way to permanently disable filesystem encryption unless it is re-enabled by a very-restricted-access tool
And how would that prevent a ransomware from implementing its own encryption ? .ZIP file ?)
(e.g.: moving all data it can manage to get access to into a huge password-encrypted
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Seriously, most of that kind of malware runs as *YOU*. If you have full access to it, it will be able to encrypt the files. Am I missing something?
--fatboy
This is more similar to something like SELinux and AppArmor.
e.g.: some attachments that you clicked on in your e-mail client, even if run as your credentials, should NOT have a valid reason to write anywhere on your folders (and attachements should not be run to begin with).
e.g.: any sub-process launched by the browser should only exclusively have the rights to write into the cache and download folder, and not anything else, even if they still inherit your session (even if the sub processes aren't changing their user id to "nobody").
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Why should apps have access to all folders by default and then (only now) there is a feature to restrict certain folders? Why should most apps access anything except their own data? Android/iOS/OSX/Web have been like this forever, what is taking so long for Windows?
You can bet that if Microsoft tries to actually seriously implement a log-structured (e.g.: actually decided to use UDF beyond optical and portable flash media) or copy-on-write filesystem (e.g.: ZFS and BTRFS on NT kernels) that supports version control, they'll botch it and there will be an exploit found making the older copies also editable by a non-admin user (the ransomware could purge the older copies and only leave the encrypted version).
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
>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.
This is ridiculous in the extreme. Anyone fearful of losing their files for any reason should be backing them up on a regular basis! So perhaps this new feature prevents files being encrypted in a ransomware attack, but what if the disk fails? Or any number of other issues?
Come on people, get a clue!
Blocked from access by all programs by default? So I go to photoshop and hit open and the open file dialog box is blocked from accessing any folder anywhere in my user directory? That's helpful. Is that really how this works or is this more like "nothing can get past the UAC" type of BS?
It's very useful if it's paired with a sensible default policy and a sensible UI. You can implement the same thing with the TrustedBSD MAC framework or SELinux, and macOS / iOS implement their sandboxing policies in exactly this way. macOS, in particular, provides a 'powerbox' model, where the standard open and save dialogs are owned by the system and implicitly grant the application permissions to the files / directories that the user selects as part of a dynamic policy. This means that well-behaved applications never need to ask for explicit privilege elevation. The problem is, well-behaved applications are generally not the ones that you most want to sandbox...
I am TheRaven on Soylent News
Its just a way to have you mark your interesting files to steal from you. Just like deleting a comment
Except that's not how it work. Defender blocks writes, it doesn't prompt. You can add white listed apps but not during a ransomware attack.
Linux is (of course) subject to that attack as well, the thing is 1) Linux users are usually more system aware and don't run anything attached in a mail 2) attacks target Windows because it's still 90+% of the running OSes (desktop wise).
Slashdot, fix the reply notifications... You won't get away with it...
This is funny only from a single-user PC perspective, but remember UNIX is a multi-user server system. Yep, if it's your files you _are_ a king. Nothing wrong here. No fool proof behaviour cause users are not considered for fools.
Users will be used to automatically say "yes" when they're trying to accomplish something (open a PDF that they just downloaded) and the prompt makes sense ("do you want to grant PDFreader access to folder Downloads?). It doesn't follow that users will therefore say "yes" to a request not related to what they're trying to accomplish.
No, I didn't read the article, but why should I when this sounds really dumb? Why not protect the entire drive instead of protecting parts of it!? If you have a method for the former, why not do it for the latter and leave it at that? Also how is this fundamentally different than the access/security settings for files and subdirectories that have existed in NTFS for decades?
So the user will be asked a number of times (probably once per appli / folder) if they agree to allow that appli to access that folder, then when they see the fake "Adobe something wants to access your folder" they will be used to automatically Yes it.
No. RTFA. They will see an error dialog that says "Access is denied. Use File>SaveAs to save under a different location or name." The only way to enable it is (1) opt in via the control panel, (2) chose apps via the control panel.
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.
Yes there is. There are even two in Linux, SELinux and AppArmor.
However, there is no easy-to-use GUI to administer it per-user, which means that you rely on the way-too-permissive default policy for most programs. This could have been done years ago technically, since SELinux and AppArmor are both quite old, but no one had the right idea apparently.
Finally! A year of moderation! Ready for 2019?
In Windows, everything runs under your users' account and almost everything else runs as root. This is similar to setting the noexec flag on the users' home partition, something that has also existed a long time.
Custom electronics and digital signage for your business: www.evcircuits.com
Is it really finer graned? To me Windows MACLs and DACLs look pretty much equivalent to SeLinux's ACLs and type labels.
"offline" being the operative word here. Backing up to a spare disk or an NFS mount still puts you at risk.
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
We had a ransomware infection on our network, and it basically tested every network share it could find, and started encrypting on network shares the user had read/write access to. Of course, we keep very thorough backups so data loss was minimal, but ransomware infections certainly go beyond local profile folders. It would be nice to see this logic more thoroughly extended to cover access to network resources.
The world's burning. Moped Jesus spotted on I50. Details at 11.
Often it's not a case of "there are no backups", but "the ransomware gets the backups too because they're read-write accessible".
IMHO, the best solution is a versioning filesystem, where deleting old versioning data requires administrator access. So ransomware "wrote over" all of your files? Big deal - rollback. So long as it can't delete old versions, the worst it can do is temporarily run you out of disk space.
I'll BUILD someone to replace you. Some kind of gamma-powered monster, with a heart as black as coal!
windows already has this. this feature is about protecting those files that programs running under your accounts would normally have access to.
Either I don't understand how it works or it can be circumvented by gaining the SYSTEM level privileges (and most Windows users say "yes" to all UAC warnings so getting the said privileges is not that difficult).
Why was this rated up when it’s not even remotely close to how the feature works?
For a lot of people, it is the opposite. Being able to encrypt or destroy someone's files is far more lucrative than getting root or Administrator rights.
What is new is the per user/per process granularity (although it really isn't new, as it has been in SELinux for years). This is important, although attacks via IAP mechanisms like Microsoft DDE can jump this... however it is a step in the right direction.
So the user will be asked a number of times (probably once per appli / folder) if they agree to allow that appli to access that folder, then when they see the fake "Adobe something wants to access your folder" they will be used to automatically Yes it.
You know Windows 10 did away with pretty much all of that, which is why Chrome can't even set itself as a default browser anymore and instead serves up instructions for the user to change it via control panel.
There is no more "simple yes".
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:
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?
The society for a thought-free internet welcomes you.
Install the File server resource manager role on a windows server and you can basically do just that. There are tons of instructions on the internet on how to use FSRM to block ransomware pretty much outright on network shares.
Relevant xkcd: https://xkcd.com/1200/
R.Mo
Because "humans" will end up saying "yes" to about everything.
Free game.
Free browser.
Similar named application.
There is no way to aid "idiots" who do not keep at least one backup of their relevant data.
Irrelevant news and morons using moderation to mod down what they disagree on. 2018 resolution: so long.
... instead of filesystem locations (or in addition to)
A ransomware needs to read and write tons files rapidly to be "effective".That's usually how people get first signals:"my pc get very slow"
Truly, they are an industry pioneer.
The beauty of the 'home directory' structure design of a UNIX system is that if malware, or a faulty application you are coding, attempts to wipe out your filesystem, the only thing it will be able to touch is your personal data, the things you actually use the computer to create and manipulate.
That 'beauty' became obsolete when personal data became more valuable than the effort it takes to rebuild a computer. The 'home directory' structure was built around timesharing mainframes, when a computer would be shared by hundreds or thousands of users and have hundreds or thousands of home directories, and non-supervisor users had no business futzing with the system or application directories or even other home directories. If one user's account got wiped, restore it from nightly backup. If the system got whacked, OTOH, that's downtime for hundreds or thousands of users while sysops spent days bootstrapping the system from tape.
Sure, the 'home directory' is a step-up from the complete non-security do-whatever that was the personal microcomputer of the 80's and 90's, but today one's personal data is much more valuable than the trouble of rebuilding a computer's OS. A person's financial existence might be stored in the 'home directory' of his PC or smartphone today. Crash the OS, a smartguy/genius can likely rescue the user data and just copy it to a fresh new device, and you're back in business. Corrupt the user data, OTOH, and you might lose your credentials to log in to the bank, pay your electric, work remotely for your employer, etc., cost you weeks trying to rebuild your life.
Corrupt the user data, OTOH, and you might lose your credentials to log in to the bank, pay your electric, work remotely for your employer, etc., cost you weeks trying to rebuild your life.
What you say is completely correct, and yet anyone whose life is so dependent on their computer really needs to have layered backups that are not on the computer in question, with a very high preference for some sort of off-site location.
I realize that most people don't do this, but they may one day come to regret it. Secure multi-generation backups are really the best defense. While it's good to see MS step up their game here, there has to be a significant degree of user responsibility.
that solution works but your devouring storage space. For a little while high capacity hard drives were making that moot, but lately Users are getting low capacity SSDs now meaning we're back to square one and space is at a premium again. I have a working folder that's managed to grow to 4 gigs over the years full of text files, database backups, documents and the like. And my dev VMs start at 4 gigs and go up.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
Why was this rated up when it’s not even remotely close to how the feature works?
Because on /. we mod up or down based on our own personal versions of what we thing reality is, not actual reality.
I browse on +1 so AC's need not respond, I won't see it.
Windows/system32/drivers/etc/hosts it's hit or miss each time I go looking for it. The ETC directory doesn't show half of the time.
(3) Bypass the whole thing via obscure twists in the giant and massively huge clusterfuck that is called WINAPI.
CLI paste? paste.pr0.tips!
Way to force a +5. Hacker.
CLI paste? paste.pr0.tips!
that's not sudo [...] to be sudo [...]
Troll harder. Or learn your fucking unix, even if it's only the Losers' Unix.
CLI paste? paste.pr0.tips!
I run my web browser and any *media stuff setuid someoneelse, you insensitive clod.
CLI paste? paste.pr0.tips!
Which is the only thing anyone can do.
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.
Err why? No really think about that. What usage scenario would Flash or Chrome have that requires writing to e.g. Documents directory?
It seems like they haven't fixed the fundamental, underlying problem of users running untrusted code
No one has. It's kind of fundamental to the operation of the computer that the user has the ability to a) run code, and b) have that code access files with their permissions.
Windows has taught them to think there's something "wrong" with their computer if JavaScript is disabled.
And there would be. One should not disable the scripting languages that render webpages, but rather sandbox them into places they become harmless. We want to do more with our computers, not less.
The irony of this is that the NTFS filesystem has had fine-grained permissions for 2 decades, but Windows never exploited it until now
Windows has exploited all the permissions since they first came out, the user defaults were just sensible enough that users never changed them. They are not unlike the Linux default permissions. Furthermore what is happening here has nothing at all to do with the filesystem or NTFS permissions. And speaking of Linux....
Why does Microsoft always get the usage model wrong?
How so? What they effectively have now is a copy of Unix permissions with SELinux bolted on top.
git is for versioning
Then what is for versioning of large non-textual files, such as large GIMP, Photoshop, or Audacity projects? Git isn't really built to handle big binaries. And what is for protecting your private Git repositories from unauthorized modification by ransomware?
Now with the new Windows structure, it won't be able to touch your personal data but it can completely replace and manipulate everything in Windows directory.
It can wipe the whole Windows directory and replace it with it's own binaries. So after rebooting, you'll finally be able to get borderless ransomware at boot instead of being windowed inside Windows.
OSX has had this feature for over a decade. It's not used a lot but you can use it. it's fairly simple to use too if you are computer savy.
It's called the sandbox. and it allows you to run an app such that there's a list of files, folders, network address, CPU levels, and all sorts of things it can or can't access.
you create a file in the sandbox direcory that might look like this
(allow file-write* file-read-data file-read-metadata
(regex "^/Users/user_name/[Directories it requires to write and read from]")
(regex "^/Applications/MyApp.app")
(regex "^(/private)?/tmp/"))
name that file something like ""myapp-sandbox-conf "
then launch any app with that wrapper like this:
sandbox-exec -f myapp-sandbox-conf /Applications/MyApp.app/Contents/MacOS/MyApp-bin
Some drink at the fountain of knowledge. Others just gargle.
Windows has had the Software Restriction Policies feature for a while now that let you control what executables can run.
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.
Yes there is. There are even two in Linux, SELinux and AppArmor.
However, there is no easy-to-use GUI to administer it per-user, which means that you rely on the way-too-permissive default policy for most programs. This could have been done years ago technically, since SELinux and AppArmor are both quite old, but no one had the right idea apparently.
Users can’t just create and load new selinux policy on the fly, GUI or not, without privilege escalation. What setuid? system would dynamically create new policy per user, and is there even a way to hook into selinux to prompt the user on policy denials? There’s a good reason nobody had this idea, it’s not remotely feasible with selinux. That’s not what it was designed for.
Users ? That's not a problem any more.
Just automate users.
aaaaaaa
You're officially almost half a century behind UNIX on basic filesystem security features. For your next update, why not consider implementing RUNLEVELS?!?
God Microsoft sucks. It's all the more embarrassing because they've been hoovering up MILLIONS (billions?) of dollars to churn out garbage, incapable of being secured, crippleware, and people have been paying them to do it. What a joke.
From the man page for chmod:
A chmod command appeared in Version 1 AT&T UNIX.
The chmod command changes FILE PERMISSIONS, including for files that are FOLDERS, as they like to call them, (or directories/subdirectories, as they're really known).
Our reign has gone on long enough. Indeed. Summon the meteors.
App Armor has a GUI and ncurses environment on OpenSuSE.
Cheap storage VM.