From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1k0tUr-0003O4-0k for mharc-grub-devel@gnu.org; Wed, 29 Jul 2020 17:20:21 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44156) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k0tUp-0003Nw-0H for grub-devel@gnu.org; Wed, 29 Jul 2020 17:20:19 -0400 Received: from mail-ot1-f66.google.com ([209.85.210.66]:40416) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1k0tUl-0001tG-Lk for grub-devel@gnu.org; Wed, 29 Jul 2020 17:20:18 -0400 Received: by mail-ot1-f66.google.com with SMTP id c25so18562634otf.7 for ; Wed, 29 Jul 2020 14:20:13 -0700 (PDT) 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=NXXZZ3Osd383X7FWDAI2MhOuyR87rqqyTVQ/eEw176s=; b=rTscdl3FbS5npCrpGgugqmggQFuq9ZX3NG0vkCh+3+gywFfpUvkCvMKthhmujO51Eq Pl9dqsaL4SOl7w3fhCVvljKR3ItMkAuie03m+NvCQdNxf3eAj0BxZRCjOtIMYh8WmRO0 WT925ECXZhOqrbjKw/P1bJ87YC/zVvkTbdDmx4rnSiNSJJzKvQtq6CJviKRMtiAkbq9I 8mLckJwSA1fDrmkJ/zPiLfBeNNxAXpTbFm7hfJrfn7z9Nh5cYm8iENcMKVEB1uzU8tvR 8H5iboyO0D1orXusFUi1kgPsUjo03D6O8qsLOjCJaZDb6Yvj0QSkqOYBRLJ1zS5RmtPS DW+A== X-Gm-Message-State: AOAM530lUoHGJO1KjZTgw95/3ICE+jN0S8k+3pr6eovu4XFmKopCuVsR /bm4OcKnk9G+IVhX/5dUfQ2fwar7eW2+jAHYbbrO4Gi2jrA= X-Google-Smtp-Source: ABdhPJwJ96CMOhREpofw3wuRhG/NFcSt5MqyHd0haCyqz5GSUo/uLErneJQps1+Rlfm7ozFsYZ5CFiFaDfI7vyJHey4= X-Received: by 2002:a9d:664a:: with SMTP id q10mr69203otm.66.1596057611975; Wed, 29 Jul 2020 14:20:11 -0700 (PDT) MIME-Version: 1.0 References: <20200729170041.14082-1-daniel.kiper@oracle.com> <20200729221217.6c441f97@leda> In-Reply-To: From: Dimitri John Ledkov Date: Wed, 29 Jul 2020 22:20:01 +0100 Message-ID: Subject: Re: [SECURITY PATCH 00/28] Multiple GRUB2 vulnerabilities - BootHole To: The development of GNU GRUB Cc: Christian Hesse , Daniel Kiper Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=209.85.210.66; envelope-from=dimitri.ledkov@surgut.co.uk; helo=mail-ot1-f66.google.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/07/29 17:20:12 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -8 X-Spam_score: -0.9 X-Spam_bar: / X-Spam_report: (-0.9 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 21:20:19 -0000 On Wed, 29 Jul 2020 at 21:20, John Paul Adrian Glaubitz wrote: > > On 7/29/20 10:12 PM, Christian Hesse wrote: > > This does not apply on top of grub 2.04. Will downstream maintainers have to > > do their cherry-picking on its own or will a maintenance branch on top of > > grub-2.04 (or what ever) be available? > > I would like to push updates to the Arch Linux repositories. > > You may want to look at the Debian package which already has the patches > applied in Debian unstable [1]. > > I'm surprised that Arch did not receive a disclosure of the vulnerabilities > under NDA since Debian and the various enterprise distributions have it > already. Disclosures were done to a subset of binary distributions that have a trust path to shims signed with Microsoft UEFI CA 2011 db key. Arch Linux does not provide shim-signed with keys controlled by Arch Linux and it doesn't provide pre-signed secureboot kernels. Reading Arch Linux documentation it seems that Fedora's shim is used together with self-signed Mok Keys. Mitigation strategy for Arch Linux will then be quite different to everyone else: 1) Update to new shim from fedora when available, as previous ones are going to be revoked by the dbxupdate from uefi.org 2) Patch Archlinux grub 3) Patch Archilinux kernel for lockdown bypass 4) Generate new MOK key, enroll it into MOK 5) Sign patched grub/kernel with the new MOK key 6) Provide instructions for users to revoke their old key via MOKX, i.e. use mokutil --mokx --import existing cert; or for example delete the old key from MOK with --delete old-cert.der This is just a rough guideline, please analyze how signing keys are controlled and used on typical Arch Linux deployment and adjust things to taste. The key point is to rotate the signing key used for shim/grub/kernel/fwupd, only use the new key to sign fixed things, and ensure that old key is no longer trusted (removed from MOK, or added to MOKX). -- Regards, Dimitri.