Rendered at 10:55:33 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
exceptione 1 days ago [-]
FYI: I had tried this exploit with rootless podman containers to write to read-only mounts, but the exploit failed. I am not sure if the default container runtime in Podman is resistant against these attacks or if it assumes Docker running containers with higher privileges, but at least it was a pleasant observation. (kernel 6.18)
tptacek 19 hours ago [-]
Are you not using OverlayFS? The exploit vector here relies on OverlayFS. What you want to reason about generally is (a) whether you have AF_ALG sockets exposed and (b) whether attackers have access to files (via inode) whose cached contents will affect other processes.
AlfieJones 1 days ago [-]
It feels like AI is speeding up bug discovery faster than security can keep up. Curious if this is temporary or just the new normal.
bbmp 23 hours ago [-]
It only getting worse now that AI is also writing bug faster than humans
l23k4 17 hours ago [-]
> faster than security can keep up
What does that even mean? Bugs are finite, at some point they'll just all be patched and you'll be left with bug-free software.
AI bug discovery getting better is an incredible advantage for defenders.
louwrentius 1 days ago [-]
Maybe I’m missing something but because of this kind of risk, an old fashioned virtual machine feels like a more robust security boundary.
itintheory 22 hours ago [-]
<always has been meme>
While containers have some useful properties, it was never intended to be, and never really functioned as a strict security boundary. We've duct-taped around that, and it's reasonably good now, but that only goes so far.
kevincox 17 hours ago [-]
The fundamental problem is that the kernel is just too huge of an attack surface. It is probably always going to have exploitable bugs. A VM (especially hardware assisted) is a relatively tiny attack surface and it shows in the amount of bugs found.
I typically say that containers (and any other isolation that shares a kernel) are good for "mostly trusted" workloads, like different teams at the same company. You want isolation against accidents more than intentional attacks.
VMs are good for just about everything if you are careful (for example what devices and hardware are exposed) but if you want ultimate isolation you want completely separate hardware. It is the only way to be sure against hardware bugs and side-channels or VM bugs.
hun3 22 hours ago [-]
No, "virtual machine" alone doesn't make things safer.
Shrink your attack surface.
Use a completely locked down seccomp. Use nsjail or gVisor for containers. Use microvm or libkrun for full OS.
Lesser attack surface is what matters. Virtualization is only half of the story.
1970-01-01 19 hours ago [-]
Robust goes both ways. It's a layer. That means it's both a boundary and an attack surface. More is..more.
What does that even mean? Bugs are finite, at some point they'll just all be patched and you'll be left with bug-free software.
AI bug discovery getting better is an incredible advantage for defenders.
While containers have some useful properties, it was never intended to be, and never really functioned as a strict security boundary. We've duct-taped around that, and it's reasonably good now, but that only goes so far.
I typically say that containers (and any other isolation that shares a kernel) are good for "mostly trusted" workloads, like different teams at the same company. You want isolation against accidents more than intentional attacks.
VMs are good for just about everything if you are careful (for example what devices and hardware are exposed) but if you want ultimate isolation you want completely separate hardware. It is the only way to be sure against hardware bugs and side-channels or VM bugs.
Shrink your attack surface.
Use a completely locked down seccomp. Use nsjail or gVisor for containers. Use microvm or libkrun for full OS.
Lesser attack surface is what matters. Virtualization is only half of the story.