- cross-posted to:
- cybersecurity@infosec.pub
- cross-posted to:
- cybersecurity@infosec.pub
You must log in or register to comment.
Doesn’t having admin privileges mean you can load any driver into the kernel anyway, including blatantly malicious drivers?
Microsoft has enforced mandatory digital signatures for drivers, and getting a digital signing key from Microsoft costs a ton of money. So, presumably they do care.
In contrast, consider nProtect GameGuard, the anti-cheat system in Helldivers 2. It is a rootkit, and runs in the kernel. Why does Microsoft permit this? Shouldn’t this be blocked? It must be using either an exploit like the article, or a properly signed driver. Either way, Microsoft could fix it – by patching the exploit, or revoking the signing key.
The fact that Microsoft hasn’t done anything about malicious anticheat rootkits is a sign that they really don’t care. They just want their payment.
I might be completely wrong, but I’ve heard that a key is only a few hundred dollars, and once you’ve got it you can sign whatever you want. I think ReactOS also used to offer free driver signing for open source projects.
So I guess if ReactOS can afford one, so can most anti-cheat companies.
I think what we’re trying to say here is FUCK kernel-based anticheat systems!
I’m not sure that’s necessarily true with enforcement of driver signing.
The latest OS kernels typically make some effort to resist arbitrary code injection even by the system administrator and sometimes goes even further against an attacker with a read/write primitive on the kernel. Linux with secure boot will refuse to load unsigned kernel modules for example.
Why’s that? I thought admin could override that
You generally cannot load whatever you want into the kernel as admin on Windows.
You have to either disable secure boot to enable changing it via command prompt, or you have to boot into a special recovery mode first that verifies you have physical access to turn it off.
Linux with secure boot is similar. Root cannot patch the kernel (without a bug). The kernel lockdown feature is activated, which enforces code signing. You have to use your physical access to change the UEFI setting to disable secure boot first or use a MOK to enable signing your own modules in such a way the secure boot chain accepts them.
Huh. I must be outdated. I didn’t know they got secure boot working. So what do you do when you need to update your kernel? Or does the fact that it comes from the package manager mean that it is allowed to update that?
Generally yes. For many distros, the kernel signing key is with the distro maintainers and so the package comes with pre-signed kernel images. For distros like Arch and Gentoo, it’s the user’s responsibility to maintain the signing key and sign each updated kernel
So why can’t root add new keys?
The firmware has to allow it, so if you’ve got physical access to the machine that’s possible. Remote access root, on the other hand, can’t tell the firmware to register new keys as long as it’s configured correctly
The package manager doesn’t have special permission. The new kernel you download is also signed for you and trusted by your system.
If it wasn’t trusted, would the next time you boot the kernel won’t load because the bootloader will refuse to load the unsigned code.
It is part of the SSSCA / CBDTPA / “Trusted” computing initiative. The large corporations want to control what you are allowed to do with your computer. This is where the phrase “digital rights management” comes from.
Pretty much. This is one particular form of damage control for an attacker who has the keys to your system. I think there were more urgent security concerns that occur in the untrusted zone.
Right?
Which is exactly what MS said.
And what’s the relevance of that closing paragraph?
Probably business as usual, NSA just needed a little more time to finish a job.
This is the best summary I could come up with:
Infosec in brief Cybersecurity researchers informed Microsoft that Notorious North Korean hackers Lazarus Group discovered the “holy grail” of rootkit vulnerabilities in Windows last year, but Redmond still took six months to patch the problem.
Researchers at Avast said they informed Microsoft of a serious admin-to-kernel exploit in a driver associated with AppLocker, the app for whitelisting software built into Windows, in August of last year.
“This presented an ideal exploitation scenario, allowing the attacker to call an arbitrary kernel function with a high degree of control over the first argument.”
Avast claims Lazarus Group used the vulnerability to obtain read/write primitive on the Windows kernel and install their FudModule rootkit, but Microsoft’s opinion on the severity of admin-to-kernel exploits meant it didn’t prioritize the matter, waiting until February’s patch Tuesday to fix the issue, which it tagged as CVE-2024-21338, with a CVSS score of 8/10.
Of admin-to-kernel issues, Microsoft said administrative processes and users are part of Trusted Computing Base for Windows, and thus “not strong [sic] isolated from the kernel boundary.”
“By providing complementary security certifications, we aim to break down barriers and create opportunities for women in Jordan, fostering a more inclusive and diverse workforce,” OpenSSF said.
The original article contains 705 words, the summary contains 200 words. Saved 72%. I’m a bot and I’m open source!
