3 ms·

Yikes... In the same doc: >"For example, the separation between kernel mode and user mode is a classic and straightforward security boundary." >"Non-boundarie

Yikes... In the same doc: >"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.

lostmsu 3y ago
What do you mean "unintuitive"? Administrator is the owner of the machine. They can do whatever they want.
- hyperman1 3y ago
  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.
  - lostmsu 3y ago
    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.
    - hyperman1 3y ago
      Thanks for your kind words. 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.
      - lostmsu 3y ago
        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.

lostmsu 3y ago

What do you mean "unintuitive"? Administrator is the owner of the machine. They can do whatever they want.

hyperman1 3y ago
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.
- lostmsu 3y ago
  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.
  - hyperman1 3y ago
    Thanks for your kind words. 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.
    - lostmsu 3y ago
      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.