Re: xz meltdown/Lasse Collin

On Mon, 2024-04-15 at 11:00 -0700, Kees Cook wrote:
> 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

Fortunately vigilance on commit review caught that one ...

> 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.

So on this point, I think we can't help much with build tools (except
being careful in trying to avoid making them a large set of
dependencies).  The distros have to rely on their own vetting for tool
based build contamination.

For the build scripts, we mostly have them checked into our tree; the
only exceptions being the spec/rules files.  I've been tending to push
back on Google demands (in the name of SLSA) to include these files in
other project repositories because they're very distro specific so it
looks like a scaling problem.  I'm still inclined to think that as long
as a distro has a commit process around their spec/rules files and the
build environment, that's good enough and they don't have to be in our
tree, but I suppose it's a point to be considered at least.

Regards,

James