Re: xz meltdown/Lasse Collin

James Bottomley <[email protected]> writes:
> 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).

On that note, I notice that Fedora builds numerous non-kernel packages
as part of the kernel build, ie. in the same chroot.

I see: perf, libperf, python3-perf, bpftool, rtla, rv.

Which adds numerous dependencies:
  audit-libs-devel
  binutils-devel
  bison
  flex
  gettext
  java-devel
  libbabeltrace-devel
  libbpf-devel
  libcap-devel
  libcap-ng-devel
  libtraceevent-devel
  libtracefs-devel
  ncurses-devel
  newt-devel
  perl(ExtUtils::Embed)
  python3-docutils
  python3-setuptools
  xz-devel
  zlib-devel

From a quick look Debian does something similar.

Arguably that's a distro bug, ie. they should be built separately, but
AIUI it stems from the fact that they are all kept in the kernel tree.

cheers