From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.3 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 02B5FC433DF for ; Mon, 15 Jun 2020 17:03:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C39532078E for ; Mon, 15 Jun 2020 17:03:20 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="ZdDL5AnK" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729956AbgFORDU (ORCPT ); Mon, 15 Jun 2020 13:03:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33678 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729354AbgFORDU (ORCPT ); Mon, 15 Jun 2020 13:03:20 -0400 Received: from mail-lj1-x243.google.com (mail-lj1-x243.google.com [IPv6:2a00:1450:4864:20::243]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C78F8C05BD43 for ; Mon, 15 Jun 2020 10:03:19 -0700 (PDT) Received: by mail-lj1-x243.google.com with SMTP id 9so20118979ljc.8 for ; Mon, 15 Jun 2020 10:03:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=h+e+6oiMfPcuzfOioIuAZY78N0uqSVxHMMheHIvnJFI=; b=ZdDL5AnKuDKjT78TYGdiLM90FU4CSgVPQvBPwBxI4352g9rT5orcRSoCEyhOgCzmrb 4e5RDz3iPk4xgm/IQFSISxou4eEhtOFpaahQc3QKC4aym1agnSpfRVXS8vTqXb2Plmrd JE+g5jt9NSl4Bg3MUUdIcJO1AZwUTx6w0nfikkonIXSuSDXlbWYxbECK8lmFLj4afdYC HrXWm/+8PH0LuJZpduXLjdnuoL+cnyvy/wanzTOdUAr9jrz/ji7YRX+MTUSO0WBJYFXJ eCTY/xUIKoC3WPvskinA4vXddp2oIjFSeL+i1Yt4RZNpAH1rkFIT1NsfcEEsKZQU8Oth aD0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=h+e+6oiMfPcuzfOioIuAZY78N0uqSVxHMMheHIvnJFI=; b=EsVE59CIMCp6yZCcKE2ArhkGTceMt1ZSg4QvQz+15sLRWLYML6JzTpnnJu599xzzsP itxVx+nKSBq0qO1GpGvCimFseO4sXCa7HtwEG99jYdEiNjLHNF1An4rsHHhtKdAWWTNS D0vgD6xfElpxY99NdaIyEO5pEy1NIAVPSQr05XFyZpSVAnqcfnDKPBwv+NTZZ7dNGUXe q7Tal/uBjyqm/d+wWpJqXqhG6RMkNJ4/k4+jRzI72yErVeN8+vqbD1uomLlFJyRm/wlH vmxeMf4ZspJcxtUm370M+oQ/JMZtKLBmjscw3kHudQEsDBCdnrtcxT3D22TbpWAidRWA 1Jvg== X-Gm-Message-State: AOAM533QMWS8t75o6res+HHHCxVCc0adoZoShqvZJxjo2UoPBzvEojWE XKREgb++HEyjj4JLKsjvwZtaxW6YLHXAQnIWlWZiJw== X-Google-Smtp-Source: ABdhPJxKghjauWCQ06S7R7giwAOWLRv8YnNXKPN82l+nvWY9jbQW3XjbsykSVqW3lMHbTPuJcLGB8eKa4JCQbYJKd3Y= X-Received: by 2002:a05:651c:38b:: with SMTP id e11mr12109574ljp.415.1592240597617; Mon, 15 Jun 2020 10:03:17 -0700 (PDT) MIME-Version: 1.0 References: <206DB19C-0117-4F4B-AFF7-212E40CB8C75@oracle.com> In-Reply-To: <206DB19C-0117-4F4B-AFF7-212E40CB8C75@oracle.com> From: Jann Horn Date: Mon, 15 Jun 2020 19:02:51 +0200 Message-ID: Subject: Re: [oss-security] lockdown bypass on mainline kernel for loading unsigned modules To: John Haxby Cc: oss-security@lists.openwall.com, "Jason A. Donenfeld" , linux-security-module , linux-acpi@vger.kernel.org, Matthew Garrett , Kernel Hardening , Ubuntu Kernel Team Content-Type: text/plain; charset="UTF-8" Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On Mon, Jun 15, 2020 at 6:24 PM John Haxby wrote: > > On 15 Jun 2020, at 11:26, Jason A. Donenfeld 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.