...
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 your a Shibboleth IdP is intimately attached to your an enterprise Identity management system and possibly to your an enterprise databases ; it’s and it is at liberty to provide access via a webserver to all your users and you can see the scope of risk involved; 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 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 on behalf of”.
...
We use many tools when building the Shibboleth projects and these tools themselves can be used to attack our supply chain by inserting malware into the artifacts (jar files) that they are used to produce. This would be a more advanced attack — inserting a malware packet that itself creates a malware packet in one of our distributables — but it also has a much wider attack surface. Many, many hundreds of jar files are involved in our builds (as opposed to a few tens of jars shipped) and many of them exhibit some quite startling behaviors. For example: several of these tools perform unsolicited updates from a third party website during part of normal running: in order for this to be safe there has to be security around the (usually unknown) website and the Shibboleth project are not in a position to do an audit of this for every website consulted by every tool.
Again, our defence is to ensure that all tools that have been used to build a Shibboleth project 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 tool’s development team.
...
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. We To reiterate: we assume that a file and its checksum can be forgedtampered with, we need a way to valid validate the contents using some trust mechanism that can be established in an entirely different way. Digital cryptographic signing is a usual mechanism to achieve 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 areannounce themselves to be, that they have not been tampered with, or have not been submitted by someone who is not in the project.
...
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.
As part of our build, we check the signatures for the jars that we ship using the keys certificates in this library, thus addressing the first threat model. At the end of the build the entire library of jar files implicated in the build process is similarly checked, addressing the second threat model. All our Java products are built in an isolated build environment, starting de novo for each build and so we can feel slightly assured that nothing has slipped by.
...
It is important to understand that as a product team, making your signing certificate available is really important. Whilst is is inconvenient, without having a signing certificate available in a trust worthy location you are rendering your products open to being hijacked and misused. Further an important part of your user community will not be able to use your latest versions leaving you open to heightened support costs.
Under the current regimerules the Shibboleth project use, when faced with the situation of not being able to trust a jar file the Shibboleth project we will generally refuses 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.
...