On Sun, Aug 30, 2026 at 03:19:20PM -0500, Aaron Rainbolt wrote:
>
> I don't think that's accurate. Quoting the article, "This is what the
> agent used for the final exploit chain: three 0-days (at time of
> discovery) and one patched vulnerability that didn’t make it to my
> distribution kernel (because it was not recognized as a security
> issue)..."
The thing about an exploit chain is that if you can prevent one of the
vulnerabilities in the exploit chain, you can prevent the attack.
> The tables below that show that *at least* two additional 0-days were
> found but not used in the exploit chain. So we have a problem where not
> only are 0-days readily discoverable by powerful enough agents, but
> even known and fixed vulnerabilities are still ripe for the picking
> when attacking a stable distro (or at least a sufficiently old stable
> distro).
Part of the problem is many of the hyperscalers don't use qemu as
their VMM. They might use their own proprietary VMM, or they might
use one of the open source Rust-based VMM's, such as Cloud Hypervisor
or crosvm. (Both Android and ChromeOS use crosvm).
So there has been a lot of focus by the hyperscalers in fixing the
virtualization stack that *they* use, which means fixing
vulnerabilities in the host kernel's KVM layer, and whatever VMM(s)
they might be using.
An exploit chain will typically involve a zero-day to break the guest
kernel, and then exploiting a vulnerability in the kernel's kvm layer,
and then the VMM (qemu or chv or crosvm) running in host OS.
So it's not surprising to me that there are a lot more patched
vulnerabilities in the kernel compared to qemu. This is also why I
suggested using something like seccomp-bpf to protect the VMM. It
adds one more layer that the attacker has to work around before they
can get root on the host OS.
Cheers,
- Ted
