Hacker News Reader

HNHacker News

Top New Best Ask Show Jobs

Comment by catlifeonmars | Hacker News Reader

Parent Full thread

catlifeonmars·

GP said

> They ran it without a jailer

And you said

> getting code execution behind the jailer is still effectively game-over

So I’m really confused, which is it?

View on HN

Both, maybe? I mean: whether or not they broke the jailer, we know the jailer is breakable; it wouldn't really even be newsworthy to have an LPE that breaks the Firecracker jailer.

Did they break the jailer? I thought from these comments they disabled it.

then the breach happens in KVM? Isn’t KVM its own software repo, and firecracker sits on top? How is this firecracker and not a KvM thing

They C debugging APIs and root permissions in the Host OS to exploit a user mode process in the Host OS. Fire is hot. Water is wet.

The jailer doesn't give you debugging APIs to work with. Jailed, if your original exploit only gives you RCE in Firecracker itself, you still need another LPE vulnerability to break the sandbox.

If they have arbitrary code execution in the Linux kernel itself (which it feels like maybe they should?) then the jailer is a nonfactor. But the exploit they write up sure seems like it's just getting code execution in userland from Firecracker itself.

memory_fd = open("/dev/mem", O_RDWR | O_SYNC | O_CLOEXEC); mapping = mmap(NULL, PAGE_SIZE_U64, prot, MAP_SHARED, descriptor, (off_t)alias_gpa_for_hpa(page_hpa));

Sure looks like a C hello world kernel debugger.

The jailer exposes neither /dev/mem nor anything you could use to make the device node for it.

I deeply love my idiot comment about not using password for your password generated useful stuff. Kudos to everyone here who rescued my idiocy. Now to change my luggage combination.

It really is a great feeling; all my favorite HN threads (that I was involved in) are ones I kicked off with what I felt was a dumb question.

Reply on news.ycombinator.com