It rather involved being on the other side of this airtight hatchway: System corruption caused by an administrator
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!
Light
Dark
16 comments
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.
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 way: *”I should never be able to do anything that could ever modify the operating system enough that it becomes broken. No user should ever have that kind of access.”*
You see this dichotomocy most starkly today when running applications on Windows:
– Notepad runs as me, and is allowed to open all files i am allowed to open, because **i** am allowed to open all files i’m allowed to open
This is pretty obvious: an application acts on my behalf, so it can do anything i can do.
But now you have a Facebook/Smartphone generation who believe that if I download an app on my PC, it should **not** be allowed to just open any file I’m allowed to open.
> “If i download Photoshop, it should not just be **allowed** to browse **My Pictures** and start reading files on my device.”
They have this (mistaken) belief, that apps should not be allowed to do anything on my device without explicit additional permission.
> “An e-mail application shouldn’t just be allowed to read my contacts from Outlook.”
Yes, it should. An app should be able to do anything you can do, and do so without additional permission.
– so if they don’t think MS Paint should be allowed to open images in My Pictures folder
– you can see why they don’t think an Administrator should be allowed to administrate
Yes, Microsoft has been **begging** developers since the late-1990s, the Windows Logo program, and the **Application Specification for Microsoft Windows 2000** (https://archive.org/details/win2000appspecserverv1.2): don’t run as administrator, don’t require an administrator.
“Delete system32” is even a meme, but I guess this submitter never saw it or failed to take the obvious lesson from it.
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 form letter”.
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 “is this a valid bug for the bounty program or not?” to “why is this bug only worth $100, when I claim it’s worth $100,000?”
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.
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 more about privilege deescalation. Is there a way to deescalate privileges for a service that “requires” admin rights apart from using a restricted sid with WRITE RESTRICTED?
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 to the entire VFS.
this comment has been deleted.
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 ALL permissions to an account then there was to grant SOME permissions to an account. That seemed like the right way to do things.
Look up Windows Sandbox
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 up… 🤔
+42 points for the HHG2G reference
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 macOS versions: this takes away from the administrator account (the “root” user in Unix parlance) write access to not only the operating system itself, but also to most of its security-critical configuration files, which can now only be edited through system GUI interfaces that prevent more damaging edits. The idea is that malware that gets run as “root” no longer can infiltrate the TCB to install a “root kit” that hides its presence. So that kind of of protection is doable, but can also be rather inconvenient: it can break a lot of perfectly legitimate things that system administrators might want to do with their systems (e.g., using scripts to automate configuration changes). [SIP can still be switched off on current macOS versions, but that requires each time a reboot into a separate recovery-mode OS, such that malware can’t do it.]