From: Kees Cook <keescook@chromium.org>
To: James Bottomley <James.Bottomley@hansenpartnership.com>
Cc: Vegard Nossum <vegard.nossum@oracle.com>,
"H. Peter Anvin" <hpa@zytor.com>,
"tech-board-discuss@lists.linuxfoundation.org"
<tech-board-discuss@lists.linuxfoundation.org>,
Michael Ellerman <mpe@ellerman.id.au>,
Theodore Ts'o <tytso@mit.edu>
Subject: Re: xz meltdown/Lasse Collin
Date: Mon, 15 Apr 2024 11:00:02 -0700 [thread overview]
Message-ID: <202404151051.90B786EE85@keescook> (raw)
In-Reply-To: <fbd260b33a80b86e8bacca999bd2e59b55d9bfcd.camel@HansenPartnership.com>
On Sun, Apr 14, 2024 at 10:45:30AM -0400, James Bottomley wrote:
> On Sun, 2024-04-14 at 12:21 +0200, Vegard Nossum wrote:
> > On 13/04/2024 15:16, James Bottomley wrote:
> > > 2. We need better build artifact transparency generally but I
> > > think
> > > the kernel is fine here: we still use make so don't have the
> > > huge
> > > build artifact issue that allowed the exploit in and we have
> > > a
> > > documented signing process for our build artifacts (kernel
> > > tarballs).
> > > 3. The indirect library dependency problem doesn't apply to us.
> >
> > While this is technically true, there are many other ways to
> > compromise the kernel build process:
>
> #define injection and environmental injection have to be done on the
> build system (I mean so did the xz payload injection but it found a
> carrier in the autoconf files). We're getting better at hermetic
> builds and other things that make direct build system tampering more
> difficult to pull off. Hopefully, one day soon, we'll get to
> reproduceable builds that someone outside the distro will be able to
> check every distro binary ... and that would pick up almost any type of
> build system injection attack.
The kernel has worked fine for years with regard to reproducible
builds[1]. I regularly inter-build binary comparisons[2]. The main
thing needed is keeping these build variables fixed, e.g.:
KBUILD_BUILD_TIMESTAMP=1980-01-01
KBUILD_BUILD_USER=user
KBUILD_BUILD_HOST=host
KBUILD_BUILD_VERSION=1
All this said, such things would catch a malicious build host, but not
malicious build dependencies. For example, the groundwork was already
being laid[3] by "Jai Tan" to inject a build-time attack:
+eval "$($XZ --robot --version)" || exit
Any tool installed on the distro that the kernel depends on could
manipulate the build environment. We could certainly enforce better
sanity checks (i.e. sh-lint all the shell scripts), but defending
against obfuscated backdoors has always been tricky.
-Kees
[1] https://docs.kernel.org/kbuild/reproducible-builds.html
[2] https://outflux.net/blog/archives/2022/06/24/finding-binary-differences/
[3] https://lore.kernel.org/lkml/20240320183846.19475-12-lasse.collin@tukaani.org/
--
Kees Cook
next prev parent reply other threads:[~2024-04-15 18:00 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-12 17:36 xz meltdown/Lasse Collin H. Peter Anvin
2024-04-13 13:16 ` James Bottomley
2024-04-13 13:47 ` H. Peter Anvin
2024-04-13 14:12 ` James Bottomley
2024-04-14 0:11 ` Theodore Ts'o
2024-04-14 13:42 ` James Bottomley
2024-04-14 10:21 ` Vegard Nossum
2024-04-14 14:45 ` James Bottomley
2024-04-15 18:00 ` Kees Cook [this message]
2024-04-16 14:05 ` James Bottomley
2024-04-18 5:20 ` Michael Ellerman
2024-04-16 6:24 ` Michael Ellerman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=202404151051.90B786EE85@keescook \
--to=keescook@chromium.org \
--cc=James.Bottomley@hansenpartnership.com \
--cc=hpa@zytor.com \
--cc=mpe@ellerman.id.au \
--cc=tech-board-discuss@lists.linuxfoundation.org \
--cc=tytso@mit.edu \
--cc=vegard.nossum@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.