D
Don Lind
Guest
With all the ransomware issues these days, I have turned on the Ransomware protection's "Controlled folder access" feature.
I've clicked on the "Protected folders" link and added the folders I need to protect.
And I've had to use the "Allow an app through Controlled folder access" link to specify a few non-default programs that I trust.
That's all fine, and it was relatively painless.
But, I've just read about the RIPlace issue and Microsoft's response to it and, well, it seems like using the "Controlled folder access" feature is a waste of time at this point.
The RIPlace issue is that there's apparently a pretty easy way to completely circumvent the controlled folder access stuff and there's a "proof of concept" available that shows how your files can be replaced with encrypted copies of them without the "Controlled folder access" feature noticing. Details are here https://www.geekwire.com/2019/new-w...claims-potentially-unstoppable-vulnerability/ and in a couple of other sites.
From the story, it sounds like Microsoft doesn't view this as a big deal... they may fix it in some future version of Windows.
To me, this seems to be a hole in the basic functionality that is big enough to drive a truck through. This issue was disclosed to Microsoft (and other security vendors) six months ago. The PoC is publicly available now. Ransomware authors have probably already started using it.
How can this not require an immediate "patch Tuesday" fix?
I don't go wading into the cesspool corners of the internet and I don't blindly click on links or run attachments.
I have some offline backups, but ransomware is getting way too common and I don't want to be a victim.
I viewed the "Controlled folder access" as something that could help.
I know all news stories aren't necessarily always exactly correct and maybe the stories have not relayed Microsoft's stance correctly. But both geekwire and bleepingcomputer make it sound like the basic response is "this isn't a bug... it's an expected functionality because of the use of an older, legacy API call... and it's no big deal." And if Microsoft is going to ignore the issue and/or "slow roll" any fix for this issue, I find that troubling.
More...
I've clicked on the "Protected folders" link and added the folders I need to protect.
And I've had to use the "Allow an app through Controlled folder access" link to specify a few non-default programs that I trust.
That's all fine, and it was relatively painless.
But, I've just read about the RIPlace issue and Microsoft's response to it and, well, it seems like using the "Controlled folder access" feature is a waste of time at this point.
The RIPlace issue is that there's apparently a pretty easy way to completely circumvent the controlled folder access stuff and there's a "proof of concept" available that shows how your files can be replaced with encrypted copies of them without the "Controlled folder access" feature noticing. Details are here https://www.geekwire.com/2019/new-w...claims-potentially-unstoppable-vulnerability/ and in a couple of other sites.
From the story, it sounds like Microsoft doesn't view this as a big deal... they may fix it in some future version of Windows.
To me, this seems to be a hole in the basic functionality that is big enough to drive a truck through. This issue was disclosed to Microsoft (and other security vendors) six months ago. The PoC is publicly available now. Ransomware authors have probably already started using it.
How can this not require an immediate "patch Tuesday" fix?
I don't go wading into the cesspool corners of the internet and I don't blindly click on links or run attachments.
I have some offline backups, but ransomware is getting way too common and I don't want to be a victim.
I viewed the "Controlled folder access" as something that could help.
I know all news stories aren't necessarily always exactly correct and maybe the stories have not relayed Microsoft's stance correctly. But both geekwire and bleepingcomputer make it sound like the basic response is "this isn't a bug... it's an expected functionality because of the use of an older, legacy API call... and it's no big deal." And if Microsoft is going to ignore the issue and/or "slow roll" any fix for this issue, I find that troubling.
More...