3 ms·

A local privilege escalation to root via an exploitable service? Doesn't Linux have one of these CVEs...each week?

hsbauauvhabzb 6mo ago
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?
hnlmorg 6mo ago
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.
- GuestFAUniverse 6mo ago
  Intentionally? Ignorance is bliss! Simply use docker in its (old) default setup, instead of podman, apptainer, docker-rootless ... and that world is yours. Added bonuses are the incredible stupid integration with ufw on Ubuntu, images with laughable uid mapping, ... How that shit got traction baffles me.
  - hnlmorg 6mo ago
    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.
BodyCulture 6mo ago
No.
IshKebab 6mo ago
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.
- hnlmorg 6mo ago
  > 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.
  - IshKebab 6mo ago
    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.
    - hnlmorg 6mo ago
      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.
      - IshKebab 6mo ago
        > If you require password authentication when running sudo then an attacker has to find a RCE exploit and then crack a password. Nope! Just alias sudo to something that logs the password.

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?

hnlmorg 6mo ago

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.

GuestFAUniverse 6mo ago
Intentionally? Ignorance is bliss! Simply use docker in its (old) default setup, instead of podman, apptainer, docker-rootless ... and that world is yours. Added bonuses are the incredible stupid integration with ufw on Ubuntu, images with laughable uid mapping, ... How that shit got traction baffles me.
- hnlmorg 6mo ago
  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.

BodyCulture 6mo ago

No.

IshKebab 6mo ago

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.

hnlmorg 6mo ago
> 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.
- IshKebab 6mo ago
  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.
  - hnlmorg 6mo ago
    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.
    - IshKebab 6mo ago
      > If you require password authentication when running sudo then an attacker has to find a RCE exploit and then crack a password. Nope! Just alias sudo to something that logs the password.