Analysis of Backdoored XZ Utils Build Process with Harden-Runner

Introduction

This is a living document. We are actively working on this analysis. We will keep this document up to date as we make progress.

The recent XZ Utils supply chain security incident has sent shockwaves through the industry. XZ is a general purpose data compression format present in nearly every Linux distribution, both community projects and commercial product distributions.

As per the CVE-2024-3094, the build process extracts a disguised test file existing in the source code, which is then used to maliciously modify specific functions in the liblzma code to inject the backdoor.

We analyzed the XZ Utils build process using StepSecurity Harden-Runner and observed the injection of the backdoor. This analysis is work in progress and we have so far only analyzed the first of the two main steps in the build process.

Overview of XZ Utils build process

XZ Utils uses the GNU build system, a robust framework that facilitates software builds from source code for multiple environments. The build process unfolds in two primary phases:

1. Configure the Build Environment: Before building, you have to configure the build environment. This is done by running the ./configure script from the root of the source directory. This script checks your system for the necessary tools and libraries, determines the options that can be used to compile the program, and creates the Makefile based on the Makefile templates from the code repository.

2. Compile the Software: After configuring the build environment, you compile the software by running make. This command reads the Makefile created by the ./configure script and compiles the source code into executable binaries.

Overview of StepSecurity Harden-Runner

StepSecurity Harden-Runner is a purpose-built CI/CD security monitoring platform. Based on the lessons of past CI/CD supply chain attacks, it has detective and preventative features for CI/CD security attacks. In the context of the XZ Utils supply chain attack, StepSecurity Harden-Runner monitors file overwrite events during the build process to detect this attack technique.

Analysis of XZ Utils Build Process with Harden-Runner

In order to examine the build process of XZ Utils, we executed the configure script for both the non-backdoored and backdoored versions using GitHub Actions. The workflows were run on GitHub-hosted runners, and we monitored the runtime events using StepSecurity Harden-Runner.

Workflow used

This is the workflow used to analyze the build process with Harden-Runner. It checks out the XZ Utils source code and then runs the configure script. The first step in the workflow adds Harden-Runner to monitor the build process.

name: Build XZ Utils with Harden-Runner 
on: 
  push: 
  workflow_dispatch: 

permissions: 
  contents: read
  
jobs: 
  build_xz: 
    runs-on: ubuntu-latest 
    steps: 
      - name: Harden Runner 
        uses: step-security/harden-runner@v2 
        with: 
          egress-policy: audit 

      - uses: actions/checkout@v4 

      # Install Autotools on Linux 
      - name: Install Dependencies 
        run: | 
          sudo apt-get update 
          sudo apt-get install -y autoconf automake build-essential po4a autopoint gcc-multilib doxygen musl-tools 

      - name: configure 
        run: sudo ./configure

Non-vulnerable version – Makefile not tampered

Harden-Runner insights confirm that the Makefile at /src/liblzma/Makefile is not overwritten when the configure script is run using the tarball without the backdoor, specifically for version 5.5.1alpha. As you can see in the screenshot below, no file overwrite events were observed during the configure step by Harden-Runner.

Backdoored versions - Makefile tampered

On the other hand, when the configure script was run using the tarballs with the backdoor, in this case, for version 5.6.0, Harden-Runner insights show that the Makefile at /src/liblzma/Makefile is overwritten during the build process.

The insights provided by Harden-Runner indicate that the Makefile was modified using sed.  

Harden-Runner logs additional information in the build log about the processes called and their respective arguments. For this run, we can observe the processes executed by the configure script to modify the Makefile. The screenshot below displays some examples of such processes.

The highlighted rectangle in the screenshot shows arguments passed to sed. The execution of the sed process injects a reference to the bad-3-corrupt_lzma2.xz file into the Makefile.  

The bad-3-corrupt_lzma2.xz file being referenced here was added to the tests/files folder in versions 5.6.0 and 5.6.1 to disguise the backdoor.malicious

This analysis is work in progress and we have so far only analyzed the first of the two main steps in the build process. We will update the blog post as we make progress on the analysis.  

Summary

We analyzed the XZ Utils build process using StepSecurity Harden-Runner and observed the injection of the backdoor. Here are our observations so far:

1. When the configure script was run in the malicious version, Harden-Runner insights show that the Makefile is maliciously overwritten during the build process.  

2. We were also able to reproduce the processes executed by the build script to modify the Makefile.

This analysis shows the importance of runtime security monitoring during the build process and how it can help detect such supply chain attacks.  

References

https://www.openwall.com/lists/oss-security/2024/03/29/4

https://salsa.debian.org/debian/xz-utils/-/blob/debian/unstable/INSTALL.generic