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