It's not so widely used and it's not explained in the first couple screenfuls of TFA (which by itself is weirdly structured, taking entire paragraphs to explain when it was introduced, when it was discovered, etc. before even explaining what it actually is).
Of course the title was chosen when the article was first published on a site dedicated to security, where probably everyone knows it. This suggests that insisting on unmodified titles when republishing in HN is a poor rule.
Also one order of magnitude less than you could get on the black market for a universal Linux LPE and two orders less if you can make it work reliably.
I believe you are two orders of magnitude wrong, in the upward direction, on that number (the first of them). You're talking about reliable remote numbers there, full chain, full enablement, tranched with maintenance.
Not to mention its practically beyond Google to fix, the majority of Android phones are affected. Not as big of an issue with servers/desktops.
It's rare to get kernel (or any) updates on non-flagship phones (in billions), any compromised app on the Play store or external can get full root access instantly, but we can still rely on trust and audits when installing apps which should always be the rule.
That's not the case with browsers with random sites and ads which is hardly avoidable, having any sandbox escape is now more severe considering that it bypasses the app container/privileges on Android (second line of defense).
It requires being able to execute arbitrary code on the machine in userspace. If you have that, most of the time you don't even care about kernel level exploits.
Runpod, digital ocean's gpu cloud, and at least a few others use Linux containers for isolation between tenants (look at Wiz's blog post about the nvidia container toolkit bug; digitalocean just puts everyone in a massive k8s cluster)
They are a security boundary. The fact that you need a vulnerability to escape them is proof of that. They just don't have a particularly high cost of escape because reachable kernel vulnerabilities are so common.
If you are given a shell with `docker run -it --rm alpine:3 sh`, can you read the /etc/shadow on the host without kernel exploit? Assuming the docker and kernel are sufficiently update-to-date (e.g. latest Docker on Debian Stable).
Does Docker use user namespaces by default? Otherwise root in the container is actually root on the host, from what I read. Correct me if I'm wrong.
(Privileges are still limited by seccomp filters blocking some syscalls, and there's SELinux to block some other stuff, but it's still the actual root user without user namespaces, I think?)
That's right. Docker still runs without user namespaces by default, which means that root is the same user inside and outside of the container. This does open up attack surface and configuration footguns.
Confinement still leverages dropping some root caps, seccomp, various other namespaces, etc.
Presumably Docker's seccomp profile [1] blocks the init_module system call which is used by insmod [2]. Although, looking at the default profile, it seems to explicitly allow it, but maybe only if you have CAP_SYS_MODULE?
Root is not just one thing on modern Linux, almost all privilege checks are no gated via (slightly) more fine-grained capabilities and the default capability set for Docker containers disallows module loading (CAP_SYS_MODULE) and the relevant syscalls (namely (f)init_module) are also blocked with seccomp.
People still should use user namespaces (and tools like Podman and Incus do by default) but basic stuff like that is not the reason.
There are a million ways to load a kernel module from inside of a container into the host kernel (ie: to trigger a load), but seccomp/ linux caps will block the direct ways (as another commenter notes).
Hmm. Either I've lost my mind, or you're running a different Docker than me, or you're thinking of some strange scenario such as a Mac where docker is actually inside a VM, or you're wrong.
While there is a feature to do with UID mapping, it doesn't actually work/isn't usable/nobody uses it in current docker iirc.
Therefore root in the container very much is root on the host.
I don't think this would change anything even if it were true, which it is not. Running as root in a container opens up tons of footguns but it is not a path out of the container on its own.
My mistake, leaving out some adjective one could interpret as a misunderstanding of containers as an effective (etc.) security boundary.
This CVE demonstrates yet again that in practice containers are a layer of security (perhaps not quite as thin as the classic recommendation of running SSH on a nonstandard port, but that might be leaning toward the safer side of analogies vs. malicious code!) rather than a boundary like virtualization (not perfect but a best practice for isolation).
Not really. Generally we use "Local Privilege Exploit" to describe an exploit that goes from a reasonably normal user privileges to root privileges.
And we don't usually worry about them, because an application with normal user privileges can already to so much damage.
But this exploit can be triggered from inside a tightly sandboxed process, such as firefox's isolated browser process. Which means the attacker now only needs to chain two exploits together: One javascript exploit to get local code execution in an isolated sandbox, and this one to jump all the rest of the way to kernel mode.
Which means, you should update both firefox, and your linux kernel.
Realistically, if you have a browser sandbox, the system LPE exploit gives you very little more. Everything interesting on a desktop system is accessible by the user account directly.
Tested on three Android devices (version 9, 13, 16) with different Firefox versions under 150 (had to modify for older), two boot looped, I had to enter recovery and the other just powered off [0].
This is a big one, considering the fact that kernel updates are very rare on Android phones. Hopefully backporting is done.
Updating browsers and trusting/verifying apps is the usual way to mitigate, though this is just one click away.
Maybe browsers should employ a "New tab without JavaScript" as an option when browsing random sites/blogs, however I've seen many video decoder exploits as well.
Thanks for testing, we currently only tested it on Pixel 10, but there are a few people on our repo creating PR to support other devices, you can take a look here https://github.com/NebuSec/CyberMeowfia
I've been noodling with porting the kernel exploit to other devices, and the exploit is very sensitive to how the compiler happens to lay out stack frames. Once you figure out the right "stamp method" and offsets for a particular kernel build though, it's fairly reliable.
Mostly they’re used to enable illegal RF parameters in Europe (FCC hack); DJI disabled strict geofencing in most of the “west” several years ago and that was also enforced in the drone anyway.
Root for these RCs has been available under the guise of “FCC hack” for a really long time now; different groups have different exploits (it’s DJI so there are plenty) that work on different firmware versions.
> Two boot looped, I had to enter recovery and the other just powered off [0].
Absolutely crazy that it is possible to brick someone's phone via an exploit but ... hey.
After the power off what happened? Do things seem normal?
When it entered recovery mode where you able to get the phone in a clean state again? I take it that you did?
I'd really like to run this but I, ideally, do not want to run something random from the internet. It's a shame there is no `Dockerfile` to build this exploit/POC. All I want is LPE to `root` on a Samsung (Snapdragon) phone.
2. I saw some output from the execution of the POC.
However, after I went to <https://rootme.nebusec.io/b9e3f1a4-7c82-4d6e-9a51-2f8c4b3e0d...> the phone froze and refused to respond to any input. The only thing that worked was restarting, which I wonder how it works given the, I think, the kernel has hung. Does anyone know how the kernel is able to respond to events whilst the system has hung? The screen remains on with the partial output of the execution of the POC until the screen saver kicks in ...
The kernel is not a single-threased process - a "kernel hang" is not a very specific description and you don't have a way to know that it happened anyway. The screen timing out is evidence that the kernel was working, actually.
Comments moved to https://news.ycombinator.com/item?id=48834309, which was posted first. (Sorry! I still want to implement karma sharing so we can split credit between multiple submitters.)
82 comments
[ 0.23 ms ] story [ 94.8 ms ] threadIt's not so widely used and it's not explained in the first couple screenfuls of TFA (which by itself is weirdly structured, taking entire paragraphs to explain when it was introduced, when it was discovered, etc. before even explaining what it actually is).
Of course the title was chosen when the article was first published on a site dedicated to security, where probably everyone knows it. This suggests that insisting on unmodified titles when republishing in HN is a poor rule.
I'm all ears now
It's rare to get kernel (or any) updates on non-flagship phones (in billions), any compromised app on the Play store or external can get full root access instantly, but we can still rely on trust and audits when installing apps which should always be the rule.
That's not the case with browsers with random sites and ads which is hardly avoidable, having any sandbox escape is now more severe considering that it bypasses the app container/privileges on Android (second line of defense).
This could be the next JailbreakMe for Androids: https://en.wikipedia.org/wiki/JailbreakMe
It requires being able to execute arbitrary code on the machine in userspace. If you have that, most of the time you don't even care about kernel level exploits.
I hope not!
Many (maybe most) containers actually default to running programs as root. Kernel exploit not required.
The "root" you get in docker is not actually root outside of the namespace the container in running in.
Assuming no bugs in the kernel, it should not be able to do anything more than the UID that it's mapped from.
(Privileges are still limited by seccomp filters blocking some syscalls, and there's SELinux to block some other stuff, but it's still the actual root user without user namespaces, I think?)
Confinement still leverages dropping some root caps, seccomp, various other namespaces, etc.
[1] https://docs.docker.com/engine/security/seccomp/
[2] https://tldp.org/HOWTO/Module-HOWTO/x627.html
People still should use user namespaces (and tools like Podman and Incus do by default) but basic stuff like that is not the reason.
Not sure about running rootful though. I don't really use rootful containers personally.
While there is a feature to do with UID mapping, it doesn't actually work/isn't usable/nobody uses it in current docker iirc.
Therefore root in the container very much is root on the host.
My mistake, leaving out some adjective one could interpret as a misunderstanding of containers as an effective (etc.) security boundary.
This CVE demonstrates yet again that in practice containers are a layer of security (perhaps not quite as thin as the classic recommendation of running SSH on a nonstandard port, but that might be leaning toward the safer side of analogies vs. malicious code!) rather than a boundary like virtualization (not perfect but a best practice for isolation).
Nothing is a security boundary anymore.
And we don't usually worry about them, because an application with normal user privileges can already to so much damage.
But this exploit can be triggered from inside a tightly sandboxed process, such as firefox's isolated browser process. Which means the attacker now only needs to chain two exploits together: One javascript exploit to get local code execution in an isolated sandbox, and this one to jump all the rest of the way to kernel mode.
Which means, you should update both firefox, and your linux kernel.
Thank you for emphasizing this important detail.
> you should update both firefox, and your linux kernel
No doubt, update all the things! My point was, it can most likely wait until Monday.
from ssh to node, so much stuff showing every other week. might as well call everything remote unless you run 100% behind wireguard or something.
This is a big one, considering the fact that kernel updates are very rare on Android phones. Hopefully backporting is done.
Updating browsers and trusting/verifying apps is the usual way to mitigate, though this is just one click away.
Maybe browsers should employ a "New tab without JavaScript" as an option when browsing random sites/blogs, however I've seen many video decoder exploits as well.
[0] https://rootme.nebusec.ai
It doesn't have a web browser or, virtually, anything of use... but I think it supports enough of a web browser to log in into wifi captive portals.
This would almost surely work there too, though.
I take it you did NOT unlock the bootloader?
> Two boot looped, I had to enter recovery and the other just powered off [0].
Absolutely crazy that it is possible to brick someone's phone via an exploit but ... hey.
After the power off what happened? Do things seem normal?
When it entered recovery mode where you able to get the phone in a clean state again? I take it that you did?
I'd really like to run this but I, ideally, do not want to run something random from the internet. It's a shame there is no `Dockerfile` to build this exploit/POC. All I want is LPE to `root` on a Samsung (Snapdragon) phone.
Honor 10 - Moto G04 - Poco X3
Poco is unlocked.
There is no brick on any, they're boot loader bugs and unrelated to the exploit.
You need to modify it to root, the example only crashes the kernel.
> Absolutely crazy that it is possible to brick someone's phone via an exploit but ... hey.
It's still possible based on user agent as attackers can craft device specific payload.
The exploit/POC (call it what you want) ran or appeared to have executed because:
1. I saw output on the Firefox tab when I navigated to <https://rootme.nebusec.io/b9e3f1a4-7c82-4d6e-9a51-2f8c4b3e0d...>.
2. I saw some output from the execution of the POC.
However, after I went to <https://rootme.nebusec.io/b9e3f1a4-7c82-4d6e-9a51-2f8c4b3e0d...> the phone froze and refused to respond to any input. The only thing that worked was restarting, which I wonder how it works given the, I think, the kernel has hung. Does anyone know how the kernel is able to respond to events whilst the system has hung? The screen remains on with the partial output of the execution of the POC until the screen saver kicks in ...
It would be nice to get a `Dockerfile` to build the exploit/POC.