I wonder why Windows Defender has the privilege to alter the system files. Read them for analysis? Sure! Reset (as in, call some windows API to have it replaced with the original), why not? But being able to write sounds like a bad idea.
However, I don't know what I'm talking about so take it with a grain of salt!
AV had traditionally run as SYSTEM on Windows (and, in the past, often had kernel mode drivers too). I've always thought it was a terrible idea. It opens up exciting new attack surfaces. Kaspersky and McAfee both had privilege escalation vulnerabilities that I can recall. There have been a ton in multiple products over the years.
If malware exploits a privilege escalation vuln, what's the AV going to do about it when it's reduced to the software equivalent of a UK police officer? Observe and report? Stop or I'll say "stop" again?
AV requires great power, which requires great responsibility. The second part is what often eludes AV developers.
The OS should do the SYSTEM-level lifting and scanning processes and behavior analysis should run sandboxed as low priv processes. It would require a clearly defined API and I feel like MSFT was always reticent to commit, leaving AV manufacturers to create hacky nightmares.
Tney gave it a sexy name and set up a website about it (a github repo, at any rate), instead of just talking about it in a mailing list and getting a CVE like a proper bearded security researcher.
Probably, but is that service deployed as part of the base operating system or a third party package? Can you remove the service if you deem the crazy service behaviour is unnecessary or too risky for your usecase?
Only if you’re running daemons as root. Which would be an idiotic move to begin with because that’s not how distros package their services. So you’d have to intentionally make this mistake.
I wonder why Windows Defender has the privilege to alter the system files. Read them for analysis? Sure! Reset (as in, call some windows API to have it replaced with the original), why not? But being able to write sounds like a bad idea.
However, I don't know what I'm talking about so take it with a grain of salt!
AV had traditionally run as SYSTEM on Windows (and, in the past, often had kernel mode drivers too). I've always thought it was a terrible idea. It opens up exciting new attack surfaces. Kaspersky and McAfee both had privilege escalation vulnerabilities that I can recall. There have been a ton in multiple products over the years.
They kind of have to, though.
If malware exploits a privilege escalation vuln, what's the AV going to do about it when it's reduced to the software equivalent of a UK police officer? Observe and report? Stop or I'll say "stop" again?
AV requires great power, which requires great responsibility. The second part is what often eludes AV developers.
The OS should do the SYSTEM-level lifting and scanning processes and behavior analysis should run sandboxed as low priv processes. It would require a clearly defined API and I feel like MSFT was always reticent to commit, leaving AV manufacturers to create hacky nightmares.
Well the OS should do nothing—remember MS was taken to court over that—but better privsep on the part of the AV, sure.
Technically, Defender can be replaced with 3rd party AV.
Windows has separate SeBackupPrivilege for backup software, so why not for AV?
“Because the remediation component requires SYSTEM, the entire AV needs to run as SYSTEM and we have to unpack malware in the kernel”
Because to get Ring0, you just need signed vulnerable driver.
There are tons of signed drivers to explore ;-)
Some files under Windows are protected as the TrustedInstaller user, which is a more restrictive level of permissions than SYSTEM.
cl /std:c++17 /EHsc /W4 /O2 /DUNICODE /D_UNICODE /wd4005 /Fe:RedSun.exe RedSun.cpp advapi32.lib ole32.lib user32.lib
> normally I would just drop the PoC code and let people figure it out
Looks like that's exactly what they did though?
Or maybe they just meant that they don't usually explain how it works?
Tney gave it a sexy name and set up a website about it (a github repo, at any rate), instead of just talking about it in a mailing list and getting a CVE like a proper bearded security researcher.
A local privilege escalation to root via an exploitable service?
Doesn't Linux have one of these CVEs...each week?
Probably, but is that service deployed as part of the base operating system or a third party package? Can you remove the service if you deem the crazy service behaviour is unnecessary or too risky for your usecase?
Only if you’re running daemons as root. Which would be an idiotic move to begin with because that’s not how distros package their services. So you’d have to intentionally make this mistake.
No.
Not quite every week, but yeah it has a lot. And if the target uses sudo at all you don't even need an exploit!
But nobody mentioned Linux. There's no need for whataboutism. They both shouldn't have these vulnerabilities.