...
This document is an attempt to describe the issues we are trying to defend against, our threat models, and our defence process and why we need support from teams providing upstream tools and libraries.
Threat Models
We are specifically interested in defending against two supply chain attacks:
...
This is an attack on our users' supply chain by malware shipped as part of a Shibboleth distribution, where by the term “user” we mean someone who is deploying the Shibboleth products to provide middleware services to their users. Consider that a Shibboleth IdP is intimately attached to an enterprise Identity management system and possibly to an enterprise databases and that it is at liberty to provide trusted access via a webserver to all your users; it is easy to see that there is scope for doing a great deal of mischief.
Typically, Shibboleth distribution contains supporting libraries from outwith the project, and any of them can be a vector for injected malware. Our defence against this is to try to ensure that all third party software that we ship as part of our packages has not been tampered with since it was verified by an entity (preferably a person) that can be verified as being a member of the library’s development team. Obviously “tampered” extends to meaning “submitted “invalidly submitted on behalf of”.
Developer Supply Chain
...
When the Shibboleth project started using Maven to build its Java projects (around the time of IdP V3), the world had changed enough that some defence seemed advisable. Initially we configured our build environment such that, during a release build, all third part products and tools could only be downloaded from servers that we owned and populated. Individual developers would review a jar file before it was uploaded (and of course once it was uploaded its contents could not be changed).
The world has again moved on and it is no longer practical to do this. Rather we are constrained to use the centralized servers to source our third party libraries. Our base assumption is that downloaded binaries (from whatever source) cannot be trusted per se, no matter where they are downloaded from. For instance there are jars with the same names as those provided by the Shibboleth project up on one of these servers and the project has never been involved in doing this. To reiterate: we assume that a file and its checksum can be tampered with, ; we need a way to validate the contents using some trust mechanism that can be established in an entirely different waymechanism which is independent of the distribution mechanism. Digital cryptographic signing is a usual mechanism to enable this.
To reiterate, we are not making a judgement about the products we use, we are simply ensuring that they are what they say they announce themselves to be, that they have not been tampered with, or have not been submitted by someone who is not in the projectwhat we use is the same as what the development team produced..
What do we do?
Our defence against these threats is to check the veracity of every jar that we ship, and every jar that we download. We do this using the GPG signatures that are usually (but not always) available alongside the artifact in the centralized repository. The Shibboleth project has developed an extensive library of signing certificates and these are stored on a per (Maven) group basis: just because someone is trusted to signed something in (say) org.apache.ant doesn’t render them trusted to sign things for com.microsoft.sqlserver.
...
Under the rules the Shibboleth project use, when faced with the situation of not being able to trust a jar file we will generally refuses refuse to use the affected jar files. At the time of writing there are several projects where we do not use their latest versions because of this issue.We postulate that a situation may eventually arrive when this stops being possible: for instance if a jar file which we require to ship has a known security defect so we have to update, but we cannot find the signing key so we cannot trust it. This has yet to happen, but we have discussed this and have contingencies in place, they are likely to be very costly for all parties.