Windows 10 will use protected folders to thwart crypto ransomware

One of the &quot;features&quot; (back in the day) of running a diskless system was that you could set change policy on the server hosting the file which was completely out of reach of the &quot;client&quot; machine that was running the program. For nearly all of the system files there was no reason for them to change. NetApp turned this into a huge win when they could use snapshots to support multiple VM images with just the small configuration changes.<p>Given the well known benefit there, and that the processor on your hard drive is about as powerful as your phone, why not have the drive set up files that are &#x27;read only&#x27; unless allowed to change out of band. Here is how it would work.<p>Your disk works like a regular SATA drive, except that there is a new SATA write option which can write a block as &#x27;frozen&#x27;. Once written that way the block can be read but not written. You add an out of band logic signal and wire it up to a switch&#x2F;button that you can put on the front (and&#x2F;or) back panel. When the button is pressed the disk lets you &#x27;unfreeze&#x27; or write frozen blocks, when it it isn&#x27;t pressed they can&#x27;t be changed.<p>Now your hard drive, in conjunction with a locally operated physical switch, protects sensitive files from being damaged or modified.

Okay, so I know Windows probably doesn&#x27;t actually work this way, but from a user interface perspective... what&#x27;s the rationale on giving an App permanent access to the user&#x27;s home folder directories? Don&#x27;t most well behaved apps have a file open &#x2F; folder open dialog, which should be able to grant access to files at runtime? If the file opening dialog is provided and controlled by the operating system (I realize many, many legacy apps work differently in Windows) then the OS can silently grant permissions at the time of open, rather than letting apps either have free reign or no access at all.<p>I feel like this is the expected behavior anyway; Power Users may run utilities that need to touch the whole system, but most regular users are doing pretty good to juggle more than a handful of open files in their mental model of the machine while they&#x27;re using it. The idea of file permissions is already pretty foreign to the average end user. Applications already have a designated area (%APPDATA%) where they can store their temporary files and things, so perhaps the documents folders <i>should</i> be more locked down by default.

I&#x27;ve always wondered why Windows and other OSes don&#x27;t offer a &#x27;cold storage&#x27; area where you need thaw out files before editing. Files not modified within a selected time freeze from further modification. I&#x27;ve got plenty of files that are archived that I&#x27;d never want to change, but it&#x27;s a hassle to unmount&#x2F;remount just to add a new file to an existing directory.

My concern is first off, this seems like it is going to break a massive number of applications. It also seems that they are pushing this layer of access management that doesn&#x27;t have proper support on any platform but UWP.<p>I see this as Microsoft taking yet another step to force people to move to their new Appstore model. by choking the access to the operating system away from any other platform, which I find really amusing because their own top tier applications aren&#x27;t built on these platforms (office, visual studio, etc..).

So last ransomware we seen in the news actually tried to reboot system and encrypt files before OS is loaded. So unless that new tech gonna protect MBR (which should be protected anyway) - not sure how it going to stop encryption.

Completely unrelated, but am I the only with an impression that MS has switched Windows into a rolling release OS (like Gentoo or Arch) with infinite updates of Windows 10? This would be a genius move to solve the issue of the users remaining on the old unmaintained release like it was with XP, and like it is now with 7.

I always thought protecting users from malicious code they willingly download and run themselves is futile and a waste of developers&#x27; resources.<p>Do I miss something and this is actually a viable security approach?

&gt; If an app attempts to make a change to these files, and the app is blacklisted by the feature, you’ll get a notification about the attempt<p>So it&#x27;s allow default? That sounds useless.<p>We need a deny default thing. Like Little Snitch but for disk. Every time an app accesses a directory it hasn&#x27;t accessed before, ask. (Skip asking when files are opened using the system &quot;Open file&quot; dialog for a bit less annoyance.)

I think that the most recent attack in Ukraine already overcame this obstacle. They were able to use an in-place update system by a trusted software vendor to install their malicious code on the victim&#x27;s computer. That software would almost certainly have had permissions even under this list, so it&#x27;s not that effective.

How about using ML to detect profiles of access and disallowing un-common access patterns? If I only use VS Code to access my source, prevent win-malwr.sys from accessing that folder.

I&#x27;m surprised Google hasn&#x27;t run a Chromebook advertising campaign which just says &quot;use a Chromebook and never care about ransomware again&quot;

This sounds like a feature that will be painful to work with for regular apps, but that malware will easily work around.<p>I mean I am no security expert at all, but you kind of need administrative privilege to install a malware, so why not keep it to access all the folders you need?

This seems like a good idea, and I&#x27;m pretty excited to see this step. Though I suspect if certain apps are whitelisted to edit in those folders, ransomware will simply turn to finding exploits in those apps. And most of your document and photo editing apps out there may not have been designed with security in mind, as they never expected to be gatekeepers of file access.<p>This will also probably be a UAC-level nightmare for getting old software to work on newer PCs, as today&#x27;s software generally just assumes it can have file access to document folders.

How about we just have &quot;copy-on-write&quot; filesystems by default?<p>Something which then tries to &quot;encrypt&quot; your hard drive merely winds up creating another layer on top which you wipe out to get back the original files. You only have to flip a &quot;hardware switch&quot; when your disk fills up or you get a catastrophe.<p>I cry every time I see something that IBM or DEC got right <i>40 years ago</i> that we <i>STILL</i> haven&#x27;t adopted.

What are &quot;end-to-end security features&quot;? They mention it once but then never again.<p>As far as I know, the term end to end is about communications: an exchange between two or more parties, or endpoints, which can be encrypted &quot;end to end&quot;. I&#x27;m afraid they just dropped it as another term nobody knows the meaning of, so we&#x27;ll have to find a new term to describe why Signal and Wire are better than (non-PGP) email.

I&#x27;m skeptical. The cost of managing these permissions might outweigh the benefit. But hey, why not try it. As long as I can disable it when it ends up getting in my way...

Linux has had the same issue for the longest time: You need root or a capability to set the time, but any program you run can wipe your entire home directory.

Perhaps the place to implement countermeasures is in the disk drive (SSD these days)?<p>e.g. arrange for the drive to never delete anything unless some key exchange has recently been done, that depends on user input (bio parameters, or password).<p>From a user perspective you&#x27;d see this as :<p>All deletes (and file version changes) go to a recycle bin. Emptying the bin can only be done upon presentation of the secret.

I wonder MS has given any thought to &#x27;sealing&#x27; executable regions so no new instructions can leak into memory. IOW Once executed, a process can only reference instructions present in the binary itself. Basically make running JIT-ed code, self-modifying code, etc, a special process privilege, that can then have a limited process context for I&#x2F;O.

This seems like another strange workaround. We need to change the way the operating system behaves for the future. The problem is default allow for untrusted code to execute. Everyone recognises this as the problem, no one wants to step forward and implement the change.<p>We do it for mobile, mostly, the desktop needs the same shift.

<i>&quot;If an app attempts to make a change to these files, and the app is blacklisted by the feature, you’ll get a notification about the attempt,” Microsoft explains.&quot;</i><p>I don&#x27;t understand. If they have a blacklist, why ask the user? Or is &quot;blacklisted&quot; used loosely here to include code flagged by heuristics?

The filesystem itself is a risk: per-user default permissions so any application launched by one user can trash all his files is scary. Even applications being able to access other installed applications is dangerous. I hope the industry find a way between all closed (a la Apple) and all open.

Or &quot;Windows Will Protect Vulnerable Client Software With More Client Software&quot;.<p>Wouldn&#x27;t it be much easier and more effective to offer a one-click low cost encrypted cloud backup-service? They could bundle this with Update or Defender to offer point in time recovery.

macOS already does this.<p>System Integrity Protection.<p><a href="https:&#x2F;&#x2F;support.apple.com&#x2F;en-gb&#x2F;HT204899" rel="nofollow">https:&#x2F;&#x2F;support.apple.com&#x2F;en-gb&#x2F;HT204899</a><p>[edit] apologies, indeed, SIP only protects system files, which is not what this article is about.

This seems like a rushed reaction to recent events - I think there will be problems as a result of the rushed implementation. I could only begin to imagine the embarrassment if this was the cause of the next zero day attack.

The UI is not really explained. I hope this is not going to train more generations of Windows user to click &quot;yes yes yes&quot; in response to annoying dialogs.

.. what about the existing file versioning and backup tools?

How often are browsers affected by 0-day exploits these days?<p>I they are not, wouldn&#x27;t using web-applications and keeping your system up to date solve the whole issue?

Countdown to malware using this feature to prevent removal

To me it seams like a part of the definition of a zero day exploit makes it impossible to stop.