Google has introduced the OSS Rebuild project, designed to detect hidden changes in ready-made packages published in repositories. OSS Rebuild is based on the concept of reproducible builds and comes down to checking the compliance of a package placed in the repository with a package obtained on the basis of rebuilding from the reference source code corresponding to the declared version of the package. The toolkit 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. The number of supported repositories is planned to be expanded in the future. In practice, the toolkit allows identifying supply chain attack variants, during which, after the accounts of maintainers are compromised or sabotage is carried out within the project, a malicious update is published in the repository. At the same time, the code in the original repository of the main project remains correct, and malicious changes are made only to the finished packages.
The system automatically generates a scenario for a reproducible build of the selected package, if possible, using heuristics and selecting parameters that allow achieving identity of the artifacts supplied in the package. If it is not possible to automatically reproduce a package placed in the repository, it is possible to manually add a build specification. After the package has been reproduced, the OSS Rebuild tool saves a description of the build process for subsequent verification of new versions of the package. In addition, information is published for verification using the SLSA framework.
After verifying a specific package version, attestation data is generated, which can be used by others to evaluate already verified packages. Verification can be performed by running a command-line utility or by checking a hash stored in a separate cloud storage. The package verification infrastructure can be deployed on your own. serverYou can also use information about the checks performed by Google for several thousand packages.
Examples of different 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 substituting changes via the changed-files Actions handler:
- In the case of the XZ project, the code in the repository did not contain suspicious changes, and the malicious components that formed the backdoor were delivered inside the files used in the test set to check the correct operation of the XZ unpacker. The backdoor was activated at the build system level, and the XZ source code itself matched the code from the repository. The m4 macros for the Automake toolkit that activated the backdoor were included only in the finished archive with the code and were not in the repository. To detect such attacks, OSS Rebuild uses dynamic analysis of the artifacts delivered in the package, execution paths, and suspicious operations.
- The insertion 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 was posted to the NPM repository, including malicious changes. This release was not created in the project's Git repository, and the malicious changes were present only in the resulting package. Defense in this case comes down to identifying code in the package that is missing from the main repository.
- A compromise of the changed-files handler repository allowed an attack to be carried out on projects that use changed-files to track file and directory changes in a continuous integration infrastructure based on GitHub Actions. To protect against change substitution after a build environment is compromised, OSS Rebuild uses change and suspicious activity tracking in standardized, stripped-down build environments.
Source: opennet.ru
