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.
What would this privilege look like that is meaningfully different from SYSTEM while being properly protected from/able to deal with malware that has an LPE?
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.
That’s just the docker daemon. The actual docker services would (or at least should) still be running as its own user/group just like they would if you were running them on the host.
And that’s exactly how any reputable image would be built.
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?
> And if the target uses sudo at all you don't even need an exploit!
Why would a target executable use sudo? There are proper mechanisms for automated elevation of permissions and sudo isn’t it.
sudo is designed for user interactivity. And by default prompts for a password. However some people get lazy and disable the password entry requirement.
A target user. If you get local code execution on the account of a user that uses sudo you can trivially got root. Doesn't matter if they disabled the password authentication or not.
Of course it matters if they disabled password authentication. If you require password authentication when running sudo then an attacker has to find a RCE exploit and then crack a password. Which is waaay beyond any effort the average attacker is willing to invest. Because At that point, root access isn’t really worth the effort.
An attacker will probably just use the host for sending spam emails, bot / DDoS traffic or look for other daemons they can jump to which weren’t web accessible (eg a database).
And furthermore, if you’ve got a RCE in a daemon then that code is the running as the daemons’ user. Which shouldn’t be in the sudoers file (eg wheel group) to begin with.
Interesting. If that’s possible (I haven’t tested it, but I’m sure it is) then you wouldn’t even need to log the password. You could just alias sudo to a bash script that runs your malicious payload using the real sudo. Then the user would run the command, be prompted for their password by the real sudo, and be none the wiser that a malicious script has just been executed
For what it’s worth, Windows’ security model says it’s not an exploit that programs can grant themselves admin rights if the user is an admin (https://github.com/hfiref0x/UACME). But afaik Linux doesn’t have that model so it is a bit of an issue that this is possible
It’s literally in the opening post you replied to:
> A local privilege escalation to root via an exploitable service?
> Doesn't Linux have one of these CVEs...each week?
Why else would people be talking about docker, and user/group ownership of running services, and so on and so forth, in response to their comment and yours?
- the discussion was about how Defender might have “root” access but Linux services have CVEs too.
The reason Defender has elevated access is precisely because it needs to do stuff like hook into file system events and scan files irrespective of their underlying ACLs.
So it’s not the same as desktop anpplication exploit that would be running as the same user/group as the person logged in. And it’s also not the same as any other type of service, be that a RDBMS, web server, IRC server, nor any other type of server you might think off.
In fact this is true for both Windows AND Linux. Your average service will not have access to read user files and desktop applications are not services running as root.
I get you’re trying to make a balanced argument. And I do agree that Linux has had a great many poorly thought out design decisions (and even more problems inherent from its POSIX lineage). But the specific arguments you’re making in this thread are just misinformed and misunderstand how these operating systems work.
How are you going to do that without write access to the users home directory?
Like I said before, your RCE exploit will be running as the user and group of the service you exploited. For example www:www
So you’re not going to be able to write into Joe Bloggs .bashrc file unless Joe was stupid enough to enable write permission to “other”. Which, once again, requires the user to purposely modify the system into being less secure than its default configuration
> your RCE exploit will be running as the user and group of the service you exploited. For example www:www
Only if the exploit is through a web server or similar. If it's through the user's web browser, email client, video player, etc. etc. then you'll have write access to their home directory.
But thats not a daemon then. Thats a completely different type of exploit from the ones we were originally talking about.
Yes, if a desktop application has a bug then it can do damage. But at that point, who cares about sudo? The exploit already has access to your ssh keys, browser cookies and history (so can access banking and shopping sites), crypto-currency wallets and so on and so forth.
What an exploit has access to here is so much worse than getting root access on a desktop OS.
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.
reply