Desmond File

Blog archive

Cross-Build Injection Threatens App Security

Fortify Software is one of the leading providers of application security solutions for development shops. So when its researchers came across a new type of vulnerability that affects the application build process used in open source software projects, it got my attention.

According to Fortify, cross-build injection exploits "allow a hacker to insert code into the target program while it is being constructed." Discovered by Fortify while working with the Java Open Review Project, cross-build injection attacks represent a shift by hackers, from now-fortified OSes and applications toward the less well-protected application development stack.

Open source projects, which are typically widely distributed and employ automated compilation and other routines, offer an attractive target for cross-site injection. According to the Fortify announcement:

"Once an attacker compromises either the server that hosts a component or the DNS server that the build machine uses to locate that server, the attacker can leverage these vulnerabilities to take full control of the build machine and possibly other machines on the remote network."

I had a chance to pose some questions to Brian Chess, co-founder and chief scientist at Fortify. Here's what he had to say:

How serious is the threat posed by cross-built injection? Now that we're seeing it, can we expect to see more efforts to bring this attack to dev shops?
Once an organization has licked problems like buffer overflow and SQL injection, this might just be the easiest way for an attacker to slip code into the company. We expect that the attack will grow in popularity at the same rate that automatic dependency management systems grow in popularity. More targets equal more attacks.

Are there things dev shops can do, outside of the Fortify offerings, to defend or blunt these types of attacks? What kinds of changes to practices and infrastructure might be called for?
The first and simplest is to refrain from adopting automated dependency management systems altogether. Managing dependencies manually eliminates the potential for unexpected behavior caused by the build system.

The second is a hybrid of the traditional manual dependency management approach and the fully automated solution that is popular today: Run your own internal dependency server. The biggest advantage of the manual build process is the decreased window of attack, which can be achieved in a semi-automated system by replicating external dependency servers internally.

The third builds on the second: Introduce a system for vetting any open source code that is introduced into the build. This is the only way to make sure the code is acceptable.

Does this type of attack represent an escalation of threat as attackers move up the pipeline seeking vulnerabilities? Any thoughts on what might be next?
Absolutely. There's a thin line between virtue and vice. The more we automate, the more we leave room for abuse. We are open to attack anywhere people place trust without understanding what they are trusting. In particular, we expect to see more vulnerabilities in mobile devices and embedded systems.

You can read a white paper on the cross-build injection vulnerability here (PDF).

What development-stage security issues are most concerning to you? E-mail me at mdesmond@reddevnews.com.

Posted by Michael Desmond on 10/17/2007 at 1:15 PM


comments powered by Disqus
Most   Popular
Upcoming Events

.NET Insight

Sign up for our newsletter.

Terms and Privacy Policy consent

I agree to this site's Privacy Policy.