Tony Baer reports that Fortify has identified a new class of bug (via Matt Assay) in open source projects. The miscreants now attack at a point when the development is done and the software is prepared using a build. A build consists of constructing a software program out of its source code files. It can involve anything from retrieving the latest source code, compiling it to preparing redistributable installable packages.
As software has grown complex, builds have become compex too. Naturally they are getting more and more automated, to reduce errors and ease developers’ life. Open source projects have learnt to have some kind of gateway to supervise which code gets admitted, either as BDFLs or groups and panels. However, once a build starts, the guards fall down, under the assumption that code cannot be changed now.
The attackers are exploiting this assumption and using cross-build injection (pdf) to inject malicious code. With softwares now being built by reusing other softwares, the dependencies are completely automated. Fortify recommends by not using a fully automated dependency management.
However, I feel that it might not be feasible to make a fool-proof process. One thing we can do for sure is not write something back to the source code repository through the build process. However, we need a better way of identifying that code has been changed. I think this calls for automating the tests as well by using a process like Continuous Integration. Maybe tighter and more extensive tests should be used for release builds and milestone builds. This also means that we might have to test more of network activity and performance of the code. But in addition to avoiding the mishaps, it is also important to build mechanisms that identify that there are problems.
