Live data from Hacker News

GhostLock, a stack-UAF that has existed in all Linux distributions for 15 years

nebusec.ai

171–180 of 209 posts

Re: GhostLock, a stack-UAF that has existed in all Linux distributions for 15 years

#171

Earlier quoted context omitted.

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.

I don't think this is true, otherwise you could just load a kernel module into the host kernel from a container.

Root is not just one thing on modern Linux, almost all in-kernel privilege checks are now 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.

Re: GhostLock, a stack-UAF that has existed in all Linux distributions for 15 years

#172

Do we really need infosec companies now that a skid with claude can find decades-old kernel privesc over a weekend? Also can we talk about how bad Linux security is? At this point it's becoming a real liability to run anything on Linux that needs to be secure. OpenBSD has been around for ages, is written in C, and is really, really secure. Do they support containers yet (or microVMs)? Cuz if they do, I'm moving my wo…

Try illumos with zones. We run all critical services on SmartOS nowadays. Even linux bhyve VMs get confined inside a zone.

If there was a similar class of bug in the illumos kernel, it would also allow for a container escape, no?

There are many issues with the formulation of containers on Linux (though I think people overstate it whenever bugs like this happen) but ultimately this bug was a UAF that gave you arbitrary code execution in the kernel. Zone IDs are also just numbers in kernel memory... right?

Re: GhostLock, a stack-UAF that has existed in all Linux distributions for 15 years

#173
post #88

"Nothing could have prevented this from happening," say users of only language where this happens

Not true, it can also occur in C++, Zig, and assembly language.

Or Rust, when not sticking exclusively to safe Rust, but this is not really possible in many systems programming scenarious.

Re: GhostLock, a stack-UAF that has existed in all Linux distributions for 15 years

#174

Earlier quoted context omitted.

So I took the risk and ran it on a Samsung S26 Ultra - I will confirm the full details once I have `adb` installed and running. 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://roo…

The kernel is not a single-threaded 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 largely working, actually. Of course if some data structure got corrupted it could have affected a specific essential part of the system, such as the touchscreen driver or the display compositor.

I've created an issue in GitHub, please see https://github.com/NebuSec/CyberMeowfia/issues/46 (Samsung SM-S948B (S26 Ultra)).

It would be nice to get a `Dockerfile` to build the exploit/POC.

Re: GhostLock, a stack-UAF that has existed in all Linux distributions for 15 years

#175

Forgot to include "LPE" (local...) in the title so most of us can get back to weekending.

as if in these times there aren't hundreds of "0days" in everyone's hands waiting to be burned for situations just like this. 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.

Pretty much, the rate at which quality exploits are dropping is mind blowing.

Re: GhostLock, a stack-UAF that has existed in all Linux distributions for 15 years

#176
post #172

Earlier quoted context omitted.

Try illumos with zones. We run all critical services on SmartOS nowadays. Even linux bhyve VMs get confined inside a zone.

If there was a similar class of bug in the illumos kernel, it would also allow for a container escape, no? There are many issues with the formulation of containers on Linux (though I think people overstate it whenever bugs like this happen) but ultimately this bug was a UAF that gave you arbitrary code execution in the kernel. Zone IDs are also just numbers in kernel memory... right?

Not necessarily. Zones in illumos (and Solaris before) were designed from ground up to be secure in multitenant workloads[0]. It's quite different from the duct tape style[1] of linux containerization.

[0]https://www.usenix.org/legacy/event/lisa04/tech/full_papers/...

[1]Tape different things together and see if it holds.

Re: GhostLock, a stack-UAF that has existed in all Linux distributions for 15 years

#177

Earlier quoted context omitted.

Not counting GPU compute, what exactly is OpenBSD not useful for?

Personal laptop use with Ada Lovelace or Ampere family NVIDIA GPUs (did you mean this or CUDA, i couldnt tell), personal desktop use with unusual peripherals, dependency on ports, existence and competition of FreeBSD etc. I love OpenBSD's code philosophy (they were the first to introduce a lot of security techniques[1]) and the programs they produce, OpenSSH is a lifesaver, and I use doas for its low footprint on my…

So pretty much only GPU compute (CUDA) and exotic peripherals?

I don't see any ports dependency issues as there's been binary packages available forever. Even the install process is a lot faster than any linux I have to use at $work, not to mention easier to automate with autoinstall[0] if needed.

[0]https://man.openbsd.org/autoinstall.8

Re: GhostLock, a stack-UAF that has existed in all Linux distributions for 15 years

#178

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]. The demo modifies the wallpaper on supported Pixel devices. [0] IonStack https://rootme.nebusec.ai ____ Tip: Install a Chromium flavor browser (Chromite) separate from the main browser. Disable Javascript and hardware acce…

What Android devices did you test on exactly? 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 y…

Originally tested on non personal devices

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. Recovery "reboot" was used.

You need to modify it to root, the example only crashes the kernel.

Re: GhostLock, a stack-UAF that has existed in all Linux distributions for 15 years

#179

Earlier quoted context omitted.

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.

Surely working on Android adjusts the number upwards by a lot?

Re: GhostLock, a stack-UAF that has existed in all Linux distributions for 15 years

#180

Earlier quoted context omitted.

> Considering that it's rare to get kernel (or any) updates on non-flagship phones How the cluster f*k of the Android update situation Google has allowed this to happen really needs a regulator to step in. Planned obsolescence is supposed to be illegal in Europe.

Google is the good actor here. 7 years of updates, unlocked bootloader, support for LineageOS, etc. The reason it sucks is all the other OEMs who don't care about anything other than the current year's models.

That's Google as the hardware OEM, not Google as the OS/platform vendor. They should be standing on Qualcomm's neck until they upstream their drivers and whatever else is necessary to make it practical for anyone to run updated kernels on their hardware, the same as it has worked for PCs for decades.
Post reply on HN