3 ms·
These are local escalation of privilege exploits (becoming root from a regular user), not remote code execution. Escalation of privilege bugs are a dime a dozen
by dist-epoch 1y ago
These are local escalation of privilege exploits (becoming root from a regular user), not remote code execution. Escalation of privilege bugs are a dime a dozen.
- internetter 1y agoIt wouldn't be reasonable to expect it to be a RCE bug. That wouldn't be a kernel bug, it would be in the networking stack or software running.
- eptcyka 1y agoWhere is the networking stack running on a typical Linux deployment? (:
- internetter 1y agoYes, and most software runs on a host operating system. Vulnerabilities in the software of 3rd party developers aren’t in scope, even if it extends the kernel. Some networking tasks are delegated to the kernel, but almost all of the really risky stuff is not in the core kernel.
- singron 1y agoI think this also requires user (i.e. unprivileged) namespaces since you have to manipulate traffic control queue disciplines (tc qdisc). You normally need to be root to do this, so it's only useful as an escalation if you can do it within a namespace or you can convince some root daemon to do the qdisc manipulation for you (I think unlikely?). User namespaces opened up an enormous surface area to local privilege escalation since it made a ton of root-only APIs available to non-root users. I don't think user namespaces are available on android, and it's sometimes disabled on linux distributions, although I think more are starting to enable it. Relatedly, kernelCTF just announced they will be disabling user namespaces, which is probably a good idea if they are inundated with exploits: https://github.com/google/security-research/commit/7171625f57154db3c1a67b820d84650ece88ed2a https://github.com/google/security-research/commit/7171625f5...