On 6/15/20, Jann Horn <jannh@xxxxxxxxxx> wrote: > On Mon, Jun 15, 2020 at 6:24 PM John Haxby <john.haxby@xxxxxxxxxx> wrote: >> > On 15 Jun 2020, at 11:26, Jason A. Donenfeld <Jason@xxxxxxxxx> wrote: >> > Yesterday, I found a lockdown bypass in Ubuntu 18.04's kernel using >> > ACPI table tricks via the efi ssdt variable [1]. Today I found another >> > one that's a bit easier to exploit and appears to be unpatched on >> > mainline, using acpi_configfs to inject an ACPI table. The tricks are >> > basically the same as the first one, but this one appears to be >> > unpatched, at least on my test machine. Explanation is in the header >> > of the PoC: >> > >> > https://git.zx2c4.com/american-unsigned-language/tree/american-unsigned-language-2.sh >> > >> > I need to get some sleep, but if nobody posts a patch in the >> > meanwhile, I'll try to post a fix tomorrow. >> > >> > Jason >> > >> > [1] https://www.openwall.com/lists/oss-security/2020/06/14/1 >> >> >> This looks CVE-worthy. Are you going to ask for a CVE for it? > > Does it really make sense to dole out CVEs for individual lockdown > bypasses when various areas of the kernel (such as filesystems and > BPF) don't see root->kernel privilege escalation issues as a problem? > It's not like applying the fix for this one issue is going to make > systems meaningfully safer. > Indeed, I'm more or less of the same mind: lockdown is kind of a best-effort thing at the moment, and it'd be crazy to rely on it, considering various bypasses and differing attitudes on the security model from different subsystems. This acpi bypass is a bug, maybe, but it doesn't feel like a "real" security bug, because I'm not sure why this would be a feature somebody would want to lean on at this point in time. I wrote a PoC for this one rather than others because it seemed fun and technically interesting to poke around with acpi in this way, not because it's particularly rare or something.
