Lazarus and the FudModule rootkit: Beyond BYOVD with an admin-to-kernel zero-day
decoded.avast.io
decoded.avast.io
This is the kind of work that I look forward to doing.
From the article:
> Microsoft’s security servicing criteria have long asserted that “[a]dministrator-to-kernel is not a security boundary”
Admin -> SYSTEM while not always easy, it isn't a security boundary per-se. but SYSTEM -> kernel, there is a very well established security boundary. For example, being able to uninstall a security tool like crowdstrike falcon without an uninstall code even as admin or SYSTEM is considered a CVE if you can manage to do so. But there are tools that exploit driver vulns to and can kill EDRs like falcon from kernel mode.
With win11+ BYOVD should be a lot harder and I'm curious if even in kernel mode if a virtualization based security boundary can be kept such as LSA isolation (default in win11, optional/off in win 10).
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...
>"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.
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.
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.
> 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.
- Cyber warfare and theft
- Furthering its nuclear and missile programs
So something in common.