Google has introduced the OSS Rebuild project, aimed at identifying hidden changes in finished packages published in repositories. The OSS Rebuild functionality is based on the concept of reproducible builds and involves verifying the compliance of the package hosted in the repository with a package obtained from a rebuild of the reference source code corresponding to the declared package version. The toolkit's code is written in Go and is distributed under the Apache 2.0 license.
Currently, OSS Rebuild supports verification of packages from NPM (JavaScript/TypeScript), PyPI (Python), and Crates.io (Rust) repositories. In the future, the number of supported repositories is expected to expand. In practice, the toolkit allows for identifying supply chain attack vectors, where, after compromising accounts of maintainers or a diversion within a project, a malicious update is published in the repository. Meanwhile, the code in the main project's source repository remains correct, with malicious changes only made to the finished packages.
The system automatically generates a scenario for reproducing the selected package's build whenever possible, using heuristics and selecting parameters that ensure the identity of artifacts delivered within the package. If it cannot automatically reproduce the package hosted in the repository, manual addition of the build specification is possible. Once the package is successfully reproduced, the OSS Rebuild toolkit saves a description of the build process for future verification of new package versions. Additionally, verification information is published using the SLSA framework.
After verifying a specific version of the package, attestation data is generated, which can be used by others to assess already verified packages. Verification can be performed by running the command-line utility or by checking the hash stored in a separate cloud storage. The infrastructure for package verification can be deployed on one's own. server. Information about checks performed by Google for several thousand packages is also available.
Examples of various attack methods that OSS Rebuild could protect against include adding a backdoor to XZ, injecting malicious code into the official JavaScript client for the Solana cryptocurrency, and inserting changes through the changed-files Actions handler:
- In the case of the XZ project, the code in the repository contained no suspicious changes, while the components forming the backdoor were supplied within files used in the test suite to verify the correctness of the XZ unpacker. The backdoor was activated at the build system level, while the XZ source code matched the code from the repository. The m4 macros triggering the backdoor for the Automake toolchain were included only in the final archive with the code and were absent from the repository. To detect similar attacks, OSS Rebuild employs dynamic analysis of supplied package artifacts, execution paths, and suspicious operations.
- The injection of malicious changes into the @solana/web3.js library occurred due to the compromise of the maintainer's account, using social engineering and phishing methods. A new release containing the malicious changes was hosted in the NPM repository. This release was not created in the Git repository of the project, and the malicious changes were only present in the resulting package. Protection in this case involves identifying code in the package that is missing from the main repository.
- The compromise of the changed-files repository allowed for an attack on projects using changed-files to track changes in files and directories within GitHub Actions-based continuous integration infrastructure. To protect against changes being injected after the compromise of the build environment, OSS Rebuild employs monitoring of changes and suspicious activity in standardized stripped-down build environments.
Source: opennet.ru
