Open source projects being compromised and used to spread malware could be a thing of the past. The Linux Foundation’s software signing initiative wants to be a Let’s Encrypt for software releases.
The wide-spread use of open source is astonishing. Open source software, tools, and libraries are found in almost all non-trivial software developments that are taking place. Unfortunately, the very thing that makes open source attractive—you have access to the source code of the software and anyone can submit bug fixes and new features—presents an attack vector that can be exploited by threat actors.
Open source projects have had malicious code injected into them by cybercriminals that use the popularity of the open source product as a distribution method for their malware. Typically it will provide the threat actors with a backdoor onto the victims’ computers. It may also run a keystroke logger or download the actual malicious software from the cybercriminal’s servers.
This type of attack is a form of supply chain attack. In a supply chain attack, the victims are not directly compromised. The malicious payload is inserted into something at one of the victim’s suppliers. When the victim procures the tainted item the malicious payload is triggered and the victim is compromised. The most famous example of a supply chain attack was the one used in the Stuxnet attack on the uranium enrichment plant at Natanz, Iran.
Open source software is an obvious platform for cybercriminals to use for this type of attack. In response, the Linux Foundation is launching sigstore. sigstore is a free service—jointly developed with Google, Red Hat, and Purdue University—that software developers can use to digitally sign their software releases.
sigstore protects open source consumers from such attacks as dependency confusion attacks. These attacks dupe package managers into installing a remotely-hosted malicious version of a locally-available resource such as a library file. The package manager is told that there is a dependency in the software that is being installed and that the local library file needs to be upgraded. The remotely-hosted tainted version has a higher version number which satisfies the bogus dependency. The “upgrade” takes place and the system is compromised.
How sigstore Works
Like all signing and certification schemes, the worth of the signature or certificate is tied to the degree of trust people have in the issuing authority. sigstore uses the OpenID Foundation’s OpenID Connect which is based on the industry-standard X.509 scheme for defining and managing certificates. sigstore uses the OpenID authentication protocol to bind the certificates to the identity of the developer. Usually, this is their email address or another account identifier.
The sigstore client creates a short-duration key pair. It queries the sigstore Public Key Infrastructure (PKI) which checks for a valid OpenID Connect verification and issues a certificate if all is well. The certificate is created using the key pair values that will be used to sign the software.
An audit trail of certificates and signings is maintained as an immutable public log. The log can be used to verify software releases and certificates. It provides a publicly-accessible proof of the signature on a file. Subsequent signatures will be unique because the time and date are recorded also. This provides a set of assurances on the origins and provenance of the open source files and allows signature-based security policies to trap files that can not be verified and trusted.
If malicious code is injected into an open source project and it is not found by the merge management or code and peer review processes it could be compiled into a binary. If the binary is then digitally signed, sigstore won’t know about that embedded threat and could theoretically certify a malicious release.
In that circumstance the public signing log could be an asset to investigations into the attack, and as a means of early warning to others of a compromised binary. Systems could be built that compare the binary certificates against a database of known good and proven bad releases.
This could work in a similar way to the Have I Been Pwned website. You can manually search for your email through their website. If your email is found it means it has been included in a data breach. You’re told which data breach from which site exposed your personal details.
It’s not hard to imagine systems that would check the version number and signing authenticity against a reference database that sent back a go/no-go decision regarding a signed software release. In addition, developers could be notified each time their email address or OpenID Connect ID is been used in a signing event. If they didn’t initiate that event, it needs investigation.
Let’s Encrypt, But For Software
In a March 2021 blog post, Google describes sigstore as being like Let’s Encrypt, but for software releases. Let’s Encrypt is a free and open certificate authority that generates SSL/TLS certificates for HTTPS websites. It allows those websites to positively authenticate themselves so visitors can be certain that the website really is what it says it is. Once the identity of the website has been established, the public key information in the certificate is used by the visitor’s browser to encrypt the communications between their computer and the website. The process to get a certificate from Let’s Encrypt is automated.
The Google blog continues: “Just like how Let’s Encrypt provides free certificates and automation tooling for HTTPS, sigstore provides free certificates and tooling to automate and verify signatures of source code. Sigstore also has the added benefit of being backed by transparency logs, which means that all the certificates and attestations are globally visible, discoverable, and auditable.”
Taming the Wild West
The way open source software is used today was unimaginable only 10 years ago. The adoption of open source in the wider development world is due to more than accessibility to the source code, the code quality, and the turnaround time for bug-fixes and patches.
Open source used to be regarded with suspicion. But organizations get open source now. The open source model is recognized as having more to do with marketing and publishing than a devotion to the many variants of the GNU General Public License (GPL).
Mainly, it’s a way to get your code or product out there. Get a GitHub account, write your program, and tell people it’s available. If it’s any good it’ll grow and, hopefully, snowball. Want to get involved in an open source project? Simple. Push a merge request to their Git repository, or offer to help with their documentation.
Open source has been disruptive in the most positive of ways. But it has also been a free for all. The open source ecosystem has been crying out for something that can provide the software supply chain with transparency, verification, and auditing.
sigstore shows all the potential to fill that need with a system that is free, easy, and scalable.