Windows 10 will use protected folders to thwart crypto ransomware
helpnetsecurity.com
helpnetsecurity.com
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 'read only' unless allowed to change out of band. Here is how it would work.
Your disk works like a regular SATA drive, except that there is a new SATA write option which can write a block as 'frozen'. 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/button that you can put on the front (and/or) back panel. When the button is pressed the disk lets you 'unfreeze' or write frozen blocks, when it it isn't pressed they can't be changed.
Now your hard drive, in conjunction with a locally operated physical switch, protects sensitive files from being damaged or modified.
All it does it convert something which is currently invisible (the bad guys escalate privledges and then can stomp all over anything) to something that requires you to stop and say "ok you can stomp on things."
Typically that would be unexpected if you weren't updating the OS but sure social engineering always works as is mentioned elsewhere.
The goal is just to add depth to the security to slow them down.
This is more feasible with a file system where snapshots are efficient, like ZFS. With client-side virtualization (e.g. Qubes), snapshots can be done outside of Windows.
The average user is never going to be protected by something they can switch on and off at will. They will never understand the complexity around when it is OK to switch it off.
Really, this scheme needs to include the entire contents of the drive-- "freezing" the restore points Windows makes automatically. Now the tradeoff is how often you annoy the user/how fresh the backups will be. Once a year is obviously too infrequent, once a second is too often. Once a week, or month. Maybe do it at the same time as Windows does a system update, as you suggest.
You don't need fancy hardware support for this, just a NAS backup box with a client that doesn't let you erase older snapshots.
Point is, nobody cares about the OS files. They care about their documents and data, and their logins to various secure systems. Securing system files alone doesn't really help much.
Probably the best thing is basically to be a Chromebook - the OS is signed and locked-down, can't ever be changed except for by signed updates from the mothership. Documents are meant to be stored entirely on the cloud. No support for running (unsigned?) apps locally, and even if they did, it wouldn't do much, because all of the data is on the cloud anyways.
a software defined version would be: make an opt in sandbox for processes that ties a folder and it's content to a single executable, with the executable pinned by the operating system and let the whole thing be mediated by the kernel.
of course that's as thigh as the kernel security, but if you're worried by that, offsite incremental backups are a cheaper answer.
If you look at the time stamp history of your 'system' files on a windows system (C:\Windows\System\*) you will see that the files have a change frequency of approximately once every 3 to 6 months.
That would correlate with when you would need to flip the switch to allow an update (ie very rarely, like 2 or 3 times a year).
also, system files aren't really the target here, the issue are userland files - who cares that the os is safe when the data is crypted
Some malware gets delivered to my computer as a new file, and the code that it contains begins to execute as an admin user. Its attempts to mess around with C:\Windows is thwarted by block-level protection. Instead, it goes into C:\Users\Me and starts encrypting stuff (not block-level protected, because it's all constantly changing anyhow). So, it can't modify the Windows system files that I could just re-install anyhow, but it can modify the creative output on my disk that only exists in a month-old backup copy, or something.
Given that scenario, I'm not sure how much help the ability to write-lock blocks would be.
The difference is that it allows writes but any modifications are removed on reboot. I use it to lock down public access machines, users get a network drive they can write to but without being able to modify the OS they can't do much damage.
Not the solution your presenting but it works pretty well.
I used such a lot with floppy disks back in the 1980s.
http://www.fencepost.net/2010/03/usb-flash-drives-with-hardw...
https://eikonal.wordpress.com/2010/05/21/usb-thumb-drives-wi...
Ought to take a look again if they're available now. Even if they still only come with a few gigabytes of storage there would be some nice applications.
http://securesystems.com.au/index.php/high-assurance-silicon...
The other reason these products didn't take off is that it's really the operating or file system's job to do this. That's where it's easiest to enforce access control whether using labels or just crypto. There were and are systems that can do that with small, attack surfaces (i.e. TCB's). So, the integrators offer a combination of stronger OS's (eg trusted OS's, separation kernels) for data in use and encrypted drives for data at rest. Two examples: one of the first, security kernels (GEMSOS) enforcing MLS at FS level; a modern, crypto-oriented filesystem with small TCB usable in a variety of setting.
http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=048...
https://www.usenix.org/legacy/event/atc11/tech/slides/weinho...
The first one was deployed in the field for a variety of applications including controlled access of files. Similar kernels were used in databases. The other one could be modified to do access control (i.e. write-protect) on files that had been labeled as such by the operating system when it was in a clean state after trusted boot. It would be a configuration sent over IPC to an isolated app w/ privileged access to secure filesystem.
So, there's how I see it happening. The hard disk could also be used as an accelerator by offloading interrupt handling, some file access, and the crypto parts. The filesystem would then be mainly doing startup and handling issues reported by hardware. They'd have to be designed compatibly, though.
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'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 should be more locked down by default.
The problem is getting everyone on the store train, and to move away from classical desktop.
All my UNIX-like OSes are locked down as much as I can, and yes I do enable SELinux, AppArmor, seccomp, Gatekeeper, SPI and friends.
I do not have SELinux/AppArmor installed, I can't remember the last time I installed an antivirus and it doesn't matter, because I have backups with file versioning going back for a whole year of everything important.
My laptop could burn in a fire right now and I wouldn't lose anything.
But then I don't remember the last time I had problems with malware, because I don't install random software from shady internet sources either.
It's typical of software developers to solve social problems by automation instead of education. It doesn't work well, it never did.
Open/save file dialogs basically return just file path. Actual file access is a separate API call.
Requiring interactivity in all scenarios would hurt UX badly, as UAC story proved.
I hope we are moving to a world where apps are built of seperate processes, most of which have minimal access. If nothing else, this will make many old buggy C libraries (including code I have written) much less dangerous.
That could maybe be prevented by keeping the relevant sections of memory marked as read-only, and maybe it already is.
On macOS I've been experimenting with creating a separate keychain for storing most of my API keys. Once keys are stored securely, you can write a wrapper for each tool. The wrapper just has to read the value from the keychain and call the original. That way you lower the changes of keys being needlessly shared. It has good UX too, since it only has to prompt you when it's first used. Although for that to really work I think you have to sign the wrapper, otherwise anyone can just edit it.
https://msdn.microsoft.com/en-us/library/windows/desktop/bb7...
This is one of the "common dialogs", and as mentioned elsewhere it runs in the app's memory space so you can, if determined enough, mess about with them. They also run all your shell extensions, which is a fun place to put malicious code.
What might be viable is UAC-style privilege requesting to get out of a sandbox, but that kind of thing was really unpopular when UAC was introduced with Vista.
https://docs.microsoft.com/en-us/windows/uwp/files/quickstar...
Whereas with drives you don't have access to the file if it's not mounted, you have to know on which drive the file you're looking for is, go through the mounting process, then actually find the file. And if you want to alter the file you have to remount the entire thing, and possibly need to track down that one daemon which still has a handle open and prevents you from unmounting it.
Just use e.g. ZFS and configure it to take regular snapshots (though you may want to be careful, a few years back if a zpool got completely full things got wonky, dunno if they've fixed it, so you may want to keep some disk space outside the zpool just in case, so you can expand the zpool enough to work if it gets completely full)
I have the server at work, which only has windows desktop clients, making 1-minute snapshots with a one-day lifetime in addition to daily, weekly, monthly etc. It's very handy for the occasions where you accidentally save over a document and slap yourself in the head immediately afterwards.
Can you explain the thawing procedure, and how a normal everday user would experience it?
Seems like the classic tradeoff between better security and better UX.
Users would complain, and/or try to disable it.
"Windows eats all my hard disk!! I've updated to <windows xy>/Windows did an update and now all my disk space is gone!!! Don't update!!!!"
"New MS update steals your disk space, here's how to stop it"
And so on, and so on.
I have seen otherwise smart, famous people flip out in public when they learn that Windows has a built in window recorder. Same folks have no concerns with their video drivers doing the exact same thing.
That said, I think the only really safe way to do this is a history chain that lives off-site. That means copies to azure, and even with great crypto and blocklists, that's not going to fly in the news.
Microsoft has some interesting new security features on its roadmap. Unfortunately, 90% of them are for enterprise users-only and some only for its own applications.
It also wouldn't hurt to overhaul/replace UAC with something better, but I imagine that would require deeper architectural changes (which I think would be worth the pain).
Microsoft should also push users towards creating a Standard account when installing Windows, and setting up an Admin password, too. It shouldn't be too difficult/disruptive. They just need to create an easy process for it at installation.
The vast majority of Windows malware infections happen because users are also Admins. This alone would give Windows a huge security boost on average.
https://www.avecto.com/news-and-events/news/94-of-critical-m...
Once they do this, they could also start encrypting Windows devices by default with the Admin key, similar to how Android does default encryption.
Windows is pretty much the last major operating system not to encrypt by default. Hopefully, if they do this, they at least give users the option to keep the key locally, and not automatically upload it to Microsoft's servers, as they do now if you login to your Microsoft account.
Go to macOS user forums and you will see lots of discussions about how to turn off Gatekeeper or be "always root" user.
If the malware gets privileged access, it's game over. If it can't, good file system permissioning fixes the problem.
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't built on these platforms (office, visual studio, etc..).
The next version of Office and Note for Windows 10 are going to be store only.
At Build they also had people from Adobe, Cakewalk and Kodi showing their desktop apps ported to the UWP via the Desktop Bridge.
Like they did with WPF and Visual Studio, they are pushing everyone into the train by dragging their own devs into it.
Except Visual Studio isn't using anything newer than WPF yet, is it?
.NET developers only started taking WPF seriously after the performance improvements Microsoft did to WPF, which took place after Visual Studio team adopted WPF to prove its quality.
If you intended to do any remark regarding UWP, first WPF is not going anywhere as communicated to those that care to learn what goes at Build, and second the architecture between WPF, Silverlight and UWP is almost the same, just a few differences regarding XAML features and .NET APIs.
The primary function of UEFI Secure Boot is for Microsoft to prevent other operating systems from being installed on as many systems as they can get away with (right now there is no provision that end users should be allowed to disable Secure Boot on ARM devices, for example). The "security" functionality is an unworkable side-effect that provides a convenient fiction to accomplish that goal.
[1] https://www.reddit.com/r/netsec/comments/4wybax/writeup_of_s... [2] https://www.youtube.com/watch?v=V2aq5M3Q76U
Heck, it can even self-delete before any user logs in.
Why programs before the login screen and the screen itself don't run in a sandboxed account is beyond me.
Every windows user with a laptop is running in local admin mode. I've demonstrated this for german TV by having a file less UAC exploit install osk.exe malware, then have this send the password of the next user logging in via SMS to the "attacker". The deleting itself (and remove any anti virus install).
I find it shocking that this even works. However I'd be a liar if I didn't say it saved my arse once.
https://www.theverge.com/2015/5/7/8568473/windows-10-last-ve...
To be fair, software is a recent human endeavor, and except for Emacs, I'm not familiar with software versions over 10.
In databases, Oracle and Informix are both on version 12.
I think the lack of high version numbers is not necessarily paranoia, but simply that there isn't much software that's old enough yet.
Do I miss something and this is actually a viable security approach?
It's a virtual certainty that users will download malicious code, so as a security person you're left trying to mitigate the impact when they do.
Having a sort of firewall for file systems that's enforced by the system means that in addition to getting code to run with user privileges, the malware authors need to trick the victims into giving the software root (which might be impossible on enterprise networks), or use a privilege escalation vulnerability to do that.
Of course, people could still click through prompts, allow access to all apps due to warning fatigue, etc., but it's an improvement - if done correctly.
So it's allow default? That sounds useless.
We need a deny default thing. Like Little Snitch but for disk. Every time an app accesses a directory it hasn't accessed before, ask. (Skip asking when files are opened using the system "Open file" dialog for a bit less annoyance.)
Now, if you were to light the dish on fire, on the other hand...
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 will also probably be a UAC-level nightmare for getting old software to work on newer PCs, as today's software generally just assumes it can have file access to document folders.
Something which then tries to "encrypt" 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 "hardware switch" when your disk fills up or you get a catastrophe.
I cry every time I see something that IBM or DEC got right 40 years ago that we STILL haven't adopted.
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 "end to end". I'm afraid they just dropped it as another term nobody knows the meaning of, so we'll have to find a new term to describe why Signal and Wire are better than (non-PGP) email.
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).
From a user perspective you'd see this as :
All deletes (and file version changes) go to a recycle bin. Emptying the bin can only be done upon presentation of the secret.
They can't even get encryption right.
https://motherboard.vice.com/en_us/article/mgbmma/some-popul...
https://www.theregister.co.uk/2015/10/20/western_digital_bad...
(note that the drive is the wrong place, it doesn't know what a "file" is)
Can be defeated by "return-orientated programming", which uses only the existing instructions in the binary and a modified stack.
https://www.microsoft.com/en-us/research/wp-content/uploads/...
IIRC there are even some experimental efforts to add hardware support for CFI techniques to new processors (Intel I think?) but there's work going on to add support for it to modern compilers, which would allow you to compile libc and other system libraries with it turned on.
EDIT: It appears Clang actually ships with some CFI support already: https://clang.llvm.org/docs/ControlFlowIntegrity.html
Windows does a pretty good job of enforcing Data Execution Prevention for code which opts in.
We do it for mobile, mostly, the desktop needs the same shift.
Windows 10 does make code signing mandatory for new drivers, and the drivers must pass a suite of acceptance tests.
We used trusted stores for certificates and mobile applications, it's time for the desktop to do the same beyond drivers.
Not to say things won't creep through, but default allow needs to go for this to be truly solved, not a new feature or vendor product.
I don't understand. If they have a blacklist, why ask the user? Or is "blacklisted" used loosely here to include code flagged by heuristics?
Wouldn'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.
System Integrity Protection.
https://support.apple.com/en-gb/HT204899
[edit] apologies, indeed, SIP only protects system files, which is not what this article is about.
I they are not, wouldn't using web-applications and keeping your system up to date solve the whole issue?