RAVE for WordPress is a supply chain security tool which reproduces builds of WordPress from the source code and compares them to published packages of WordPress to verify that the packages have not been tampered with. The packages from wordpress.org are tested along with those from GitHub and various third parties.
A CI system runs on GitHub Actions which reproduces the build from the canonical sources, fetches packages published at several official and unofficial locations, and compares them all against one another to verify their integrity and identify any anomalies. An in-toto release attestation is produced for packages which pass verification.
RAVE stands for Reproduce And Verify.
- ✅
develop.svn.wordpress.org - ✅
develop.git.wordpress.org - ✅
github.com/wordpress/wordpress-develop - ✅
core.trac.wordpress.org
- ✅
wordpress.org/latest.zip - ✅
wordpress.org/wordpress-{tag}.zip - ✅
downloads.wordpress.org/release/wordpress-{tag}.zip - ✅
downloads.w.org/release/wordpress-{tag}.zip - ✅
github.com/wordpress/wordpress - ✅
build.trac.wordpress.org
- ✅
core.git.wordpress.org - ✅
core.svn.wordpress.org
- ✅
wordpressimage from Docker Hub - ✅
core-updates.wpengine.comfrom WPEngine - ✅
api.aspirecloud.netfrom AspireCloud - ✅ Bundle packages provided by FAIR
- ✅
roots/wordpress-fullon Packagist - ✅
johnpbloch/wordpresson Packagist
- ✅ MD5 and SHA-1 hashes published on wordpress.org are verified against the wordpress.org packages
- ✅ Checksums returned by
api.wordpress.org/core/checksumsare verified against file contents - ✅ Update URLs returned by
api.wordpress.org/core/version-checkare verified against expected URLs - ✅ Versions returned by
api.wordpress.org/core/stable-checkare as expected - ✅ Verifies that distributors are not offering versions newer than the latest official version
The GitHub Actions workflow runs once an hour. It verifies the latest WordPress release available when it runs.
There are several opportunities for the official WordPress package to be tampered with so that it differs from the actual source code in the source control repos. This could come via an attack on the build server, on wordpress.org or downloads.wordpress.org, from external hackers, from those in control of the wordpress.org CDN, from disgruntled members of the meta or systems teams, from anyone who gains access to accounts or credentials of such team members, or from the project lead.
- In 2007 a cracker gained access to the wordpress.org servers and added a backdoor to the WordPress 2.1.1 package. RAVE would have successfully detected this by:
- Detecting that the 2.1.1 package served by wordpress.org didn't match the package that it reproduced from the source code
- Making the backdoor code immediately visible in the diff in the failing workflow
- In 2016 Wordfence identified a vulnerability in a webhook mechanism on api.wordpress.org and demonstrated that a cracker could theoretically execute a shell command on the api.wordpress.org server. If a cracker exploited this vulnerability to modify an existing release or create a new one then RAVE would have successfully detected this by:
- Identifying a new version that didn't exist in the source repos
- Identifying a modified package that didn't match the code built from the source repos and didn't match the versions published to Packagist and Docker Hub
- Identifying any attempt to serve an update from an unexpected host name or URL in the update API response
- Identifying any discrepancies between the published SHA-1 and MD5 hashes, the published checksums, and the offers returned by the update API
There are several opportunities for unofficial WordPress packages to be tampered with so they differ from the official package. This could come via an attack on the servers distributing the packages, from external hackers, from those in control of the packaging, or from anyone who gains access to accounts or credentials of people or processes involved in the packaging or distribution.
By comparing the contents of the distributed package at its various locations with the output of building the source code, anomalies can be identified. This reduces the opportunity for malicious or unwanted code to be introduced into a WordPress package without it also being present in the source code repos, pipeline repos, and other distribution packages.
If one of the GitHub Actions workflows in this repo fails, it should be investigated to see if the failure was caused by divergent code. Any differences between packages are immediately visible in the workflow run output.
This approach:
- Does not detect malicious or unwanted code that gets committed to the Subversion source code repo and subsequently makes it into the published package.
- Does not detect a targeted attack that causes the contents of the package to vary based on a parameter such as the IP address or user agent of the client making the request.
- Does not deal with build provenance verification or software signing.
To quote reproducible-builds.org:
Reproducible builds are a set of software development practices that create an independently-verifiable path from source to binary code.
The process that builds and packages WordPress is reproducible as far as the built code is concerned, although I believe that the zip file generation does not result in a stable hash between invocations. Unfortunately the process itself is not open source. The process differs from the npm run build process in the source code because it makes some additions (eg. the Akismet plugin) and some exclusions (older default themes). The verifications performed by this repo take this into account.
The wordpress.org website provides the MD5 and SHA-1 hash of its WordPress package files. This is not enough to verify a package on its own, because the hash only represents the zip or tar file and if a package on wordpress.org was altered then its published MD5 and SHA-1 hashes could be altered too.
The WordPress open source project does not make use of package signing which could be used to verify a package. See ticket #39309 for discussion on this topic.
Therefore, this library has been created to provide a means of verifying that the contents of published packages matches the code built from the official source code repos.
RAVE generates an in-toto release attestation once it's reproduced and verified a given package of WordPress. If you trust RAVE then you can use its attestations to verify a WordPress package that you download, for example using gh on the command line:
wget https://wordpress.org/wordpress-6.8.2.zip
gh attestation verify wordpress-6.8.2.zip --repo johnbillion/rave-wordpress --predicate-type "https://in-toto.io/attestation/release/v0.1"wget https://api.aspirecloud.net/download/wordpress-6.8.2.zip
gh attestation verify wordpress-6.8.2.zip --repo johnbillion/rave-wordpress --predicate-type "https://in-toto.io/attestation/release/v0.1"If you want to download and inspect the metadata of an attestation as JSON:
file="wordpress-6.8.2.zip"
hash=$(shasum -a 256 "$file" | cut -d" " -f1)
gh attestation download "$file" --repo johnbillion/rave-wordpress
jq -r '.dsseEnvelope.payload' "sha256:${hash}.jsonl" | base64 -d | jq .No. SLSA is a security framework that improves the supply chain resilience of a software package by generating a verifiable build provenance attestation during its build and release process. RAVE independently reproduces the build for WordPress but is not part of the release process itself, therefore it is not appropriate for RAVE to generate an SLSA build provenance attestation.
Checksums for the files in the full WordPress package can be found in the checksums directory. These are provided as a convenience and should only be used for non-adversarial file integrity checks because they use the cryptographically weak MD5 algorithm and are fetched directly from api.wordpress.org.
To verify the integrity of a WordPress installation using the checksums provided in this repository:
wget https://raw.githubusercontent.com/johnbillion/rave-wordpress/trunk/checksums/6.8.2.md5
md5sum --check 6.8.2.md5MIT