Comment by akerl_
17 hours ago
It’s radically different than on by default.
Having a service that automatically starts and listens on the network is radically different from having a module that a local administrator can load.
If you want to block module loads, you’re one sysctl flag away.
> having a module that a local administrator can load
This is a successful local privilege escalation, so local administrator privs were not needed. In default configuration of all distros, apparently.
> If you want to block module loads, you’re one sysctl flag away.
The modules aren't really the point, it's that unnecessary features (to 99% of us?) were accessible by default without privs.
This is "a service that automatically starts". That's what automatic kernel module loading is for!
It's not any different from putting an always-running network service behind socket activation instead. The security boundary/risk is nearly identical between the two.
One is remotely accessible. The other is locally accessible.
The GP you were replying to mentioned a vulnerability "present by default and an attacker can trivially cause it to be loaded".
You responded contrasting a network service with an administrator-loadable module.
This is neither of those. It's an LPE, not a remote exploit. It doesn't require an administrator (root) to load anything. In context of this vuln, it's exactly analogous to socket activation. The scope of an LPE vuln is local; yes. What does that have to do with the rest of your comments?
1 reply →
[flagged]