>"For example, the separation between kernel mode and user mode is a classic and straightforward security boundary."
>"Non-boundaries: [...] Administrator to Kernel [...] Administrative processes and users are considered part of the Trusted Computing Base (TCB) for Windows and are therefore not strong isolated from the kernel boundary."
The reasoning makes sense, but that's quite a mixed message for an unintuitive nuance.
I think that used to be correct, but stopped being true around windows XP.
Before that, Administrator was the same as unix root: A person capable to administer the system for all other users.
But the average end user was not interested or capable to do the job, the computer was now personal so there were no other users, and driver manufacturers were simply not good at their job. Additionally, DRM implies you're not allowed to have full ownership of a machine anymore.
Microsoft, sick of receiving the misery of other people's incompetence and smelling DRM dollars, hollowed out Administrator. They kept the account name, as power users would rebel otherwise, but a new layer on top was created.
The almost reached conclusion: If you force it hard enough, you can gain system and kernel access, but secure boot will make sure you lose DRM at that point.
An exploit like this is why I still can say: almost.
You have no clue what are you talking about. The official documentation is linked and even quoted above. I'm impressed people can't grasp that simple statement even on this forum.
The old new thing is not very relevant for this discussion, so let's focus on the first, the 'Microsoft Security Servicing Criteria for Windows'.
This document lists when microsoft promises to fix a security vulnerability, and when they will pay out a bounty. No more, no less. By it's nature, this document is minimalist, and won't promise anything not strictly necesarry. Notice at the bottom of the document a whole list of Defense in depth features (e.g. DEP) falling outside these criteria. As they were implemented, Microsoft clearly does see value in them, even if they won't promise anything about fixing them.
So yes, an admin elevating to system and then kernel has no automatic intent to service in their security vision and is not bounty eligible.
But nothing of all this conflicts with anything in the post above. I presume microsoft will fix DRM problems. They will make life hard for people running things inside the kernel with no signature. They will annoy you if you pirate windows. None if these fall under the scope of the document.
Compare it to the current edge/bing situation. An admin can remove them from the system. But a next patch will ressurect them. Microsoft will wear you down, even if they made a promise about it.
You are just blubbing about DRM. It is irrelevant to the discussed issue. Security wise this is not a severe issue if an issue at all.
> Thanks for your kind words.
You get what you deserve for unapologetically repeating false statements already rebutted above in the very same thread with info from the primary source.
If you can bypass driver signing it's not a legit MS bug?? Bounty or not, driver signature enforcement is a security boundary, features like secureboot are invalid if an os malware can just load boot time drivers of its own.
... omg. Just stop. You are wrong in the SAME way over again. This bug does not let you bypass secure boot. The point of bypassing secure boot is gaining administrative privileges on the system, usually to access encrypted files. If you already have that privilege, you already crossed that boundary.
for crowdstrike falcon I imagine.
> SYSTEM -> kernel, there is a very well established security boundary
Not according to the Microsoft there is not. Really this should be the end of discussion. https://www.microsoft.com/en-us/msrc/windows-security-servic...
For funsies. https://devblogs.microsoft.com/oldnewthing/20221004-00/?p=10...