A security vulnerability report came in that went roughly like this:
I have found a permanent denial of service vulnerability in Windows. If you modify this administrative setting (directly via regedit, not via the user interface) to have a specific corrupted value, then when the system boots up, it will use this corrupted value and corrupt the operating system itself, rendering the system unusable. Modifying the setting back to its original value does not repair the problem. The system is permanently corrupted and must be reinstalled. I am requesting a bounty for this report.
This is a fairly cut-and-dried case of “It rather involved being on the other side of this airtight hatchway”: Modifying the setting in question requires administrator privilege, and it’s hardly a surprise that an administrator can render a system inoperable.
Breaking the system by corrupting an administrative setting is just style points. If you are an administrator and want to render a system inoperable, just delete everything in sight, starting with all the files in C:\Windows\System32. Delete anything that isn’t nailed down, and then go get your crowbar (also known as “Take Ownership” privilege) and pry up even the things that are nailed down.¹ No need to get all clever with crafting a corrupted setting.
Now, if the corruption of the setting could be triggered by means that don’t require administrator privileges, then you would have found something. But as it stands, it requires administrator permissions to perform this attack, so you’re starting on the other side of the airtight hatchway.
The finder argued that it is a security flaw that the system doesn’t prevent administrators from corrupting the setting. For example, there are some registry keys in the system that are protected from accidental corruption by making them read-only even to administrators. But these are merely safety measures, not security boundaries. It’s like putting a cover over the emergency shutoff switch in the control room: The cover doesn’t prevent anyone in the control room from pulling the switch. It merely prevents them from pulling the switch accidentally. If somebody with access to the control room really wants to pull the switch or corrupt the registry key, they can do it: They can lift the cover or take ownership of the key and grant themselves full access.
The finder also argued that the system should protect itself from installers that corrupt the setting. But if an installer can corrupt the setting, that means that the installer is running with administrator privileges, so it already can do anything it wants. And that includes removing the corruption protection and rendering the system unusable.
Mind you, preventing administrators or installers from inadvertently corrupting the setting sounds like a reasonable safety measure, and the system already does part of that by showing only non-corrupted options in the administrator user interface. And having the system recognize a corrupted value and stop itself before causing any permanent damage is a reasonable reliability measure, so thanks for pointing out the issue. But it’s not a security issue. You can’t protect against an administrator who intentionally decides to mess up their system.
¹ Another idea is to turn on BitLocker and throw away the BitLocker key. Or go into Advanced Recovery and reformat the system volume!
While it used to be the norm that the system administrator can trivially trash the operating system, by ultimately having full write access to all the security-critical parts of it (what used to be called the “Trusted Computing Base” or TCB in 1980s U.S. government security standards), this sometimes isn't the case any more today, even on desktop operating systems. A notable example is the “System Integrity Protection (SIP)” feature that Apple added in recent...
+42 points for the HHG2G reference
The “It rather involved being on the other side of this airtight hatchway” defence only goes so far. In my experience most software vendors do not know what permissions their software needs and just tell customers that it "requires" admin rights (and indeed it won't work without them because everything is opened with FULL_ACCESS). Seen from the perspective of pretty much everything running with admin rights, one might be less worried about privilege escalation and...
Literally fighting this right now at work. Backup app vendor (per blog rules they are required to remain nameless) is saying they need full read and write to the entire system. Absolutely refuses to accept full read alone saying it "doesn't work in practice" when they very clearly haven't spent any engineering time making it work. 😒
On the other hand they are pushing a zero trust product on us too... this doesn't seem to add...
The best way to deal with such programs would be some form of virtualization (not necessarily literal virtual machines). For example, one way to do it under Linux is with mount namespaces, using an overlayfs with the real VFS root as the lower layer and a tmpfs (or a persistent one if you want to save the changes) as the upper layer. This uses copy-on-write to give the untrusted program illusion of having read-write access...
Yes, a feature like jails or chroot would be good. Unfortunately Windows lacks such a feature, presumably due to the assumption that software developers would not abuse the Administrators group. It all started with the Administrators group. Maybe MSFT should make it impossible to run services as members of the group, then software vendors would be forced to change their ways. On OpenVMS there was no Administrators group and hence no easier way to grant...
Look up Windows Sandbox
this comment has been deleted.
I wonder if it would be worth the money (i.e. cheaper than having the arguments) to create a bounty system for non-security-but-still-important issues like this one. For sure the payouts would have a few less zeros, but being told you are getting "only" enough to pay for a nice lunch is likely less of a blow to your ego than being told "thanks for the work, but all you get for it is a nice...
As Simon says, I doubt it would work. But there would be a deeper ethical issue: we would be paying stupidity, and thus promoting it. Excuse me if I’m blunt, but stupidity is one of this world’s worst problems (even the worst one?), and I firmly believe that we should not promote it in absolutely no way.
I suspect it wouldn't; I've worked somewhere that ran a bounty program for bugs, where payouts ranged from $10 for the least significant bugs, up into the hundreds of thousands of dollars for the most major bugs.
When people were awarded under $10,000, many of them would argue that their bug was more serious, and that they "deserved" tens or hundreds of thousands of dollars for their discovery. All you've achieved is changing the argument from...
“Delete system32” is even a meme, but I guess this submitter never saw it or failed to take the obvious lesson from it.
I've come to realize that this sort of thinking comes from a generatation who grew up with smartphones.
In a smartphone, you don't own the phone. You are not an administrator. Nobody is an administrator. Nobody is allowed to do anything to modify the OS in any way; and users should never be able to do anything that could make their device not function.
And users are starting to feel that PCs should behave the same...
It doesn’t help either that in some human languages, including (Standard) Chinese, “safety” and “security” are the same word, and without studying it’s almost impossible for people speaking those languages to be aware of the difference between them (at least that’s been how I feel it).
No need to venture as far as Chinese.
In German (which IS comparatively close to English, isn’t it?), we have the same issue:
Both Security and Safety translate to Sicherheit in the *general* case.
In these contexts, the translation just needs to be more precise.
And given context, people will easily understand the difference – the different concepts are there, just not as easily expressed in a single generic word.
Even in English, “safe” and “secure” are largely synonymous… which is why you secure your valuables in a safe. In some contexts — including IT — security has become more associated with protection against malice rather than mishap, but I’m not sure that association is as strong in the general language.