[oss-security] lockdown bypass on mainline kernel for loading unsigned modules

Jason A. Donenfeld Jason at zx2c4.com
Mon Jun 15 17:28:57 UTC 2020


On 6/15/20, Jann Horn <jannh at google.com> wrote:
> On Mon, Jun 15, 2020 at 6:24 PM John Haxby <john.haxby at oracle.com> wrote:
>> > On 15 Jun 2020, at 11:26, Jason A. Donenfeld <Jason at zx2c4.com> 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.



More information about the kernel-team mailing list