Cross-build injection attacks (using Maven et al.)
Sander Mak
Greg Reddin
> What do you guys do in practice to prevent this? Does anyone have real-life
> experience with such an attack?
I think you raise some really good questions here, some that I've
thought about before, but skipped over because "I don't have time to
think about those things" :-)
This is where organizations like the Apache Software Foundation are
helpful. Apache frowns upon projects that don't make releases every so
often, so you're likely to have a somewhat recent release of an apache
product. It's up to you and your dependent software projects to ensure
you're using the later releases.
But in the end, we can't rely on Maven, Nexus, Apache, nor anyone else
to do our due diligence for us. If our project includes a few dozen
jars pulled in from who knows where (as do most) we must check the
provenance of the bits we're including. Who does that? I know I don't
do that enough.
As an aside, do you know if Artifactory contains the PGP checking
feature that Nexus does? We've been using the open-source version of
Nexus and are in the process of switching to the pro version of
Artifactory.
Greg
Fabrizio Giudici
> On Fri, Mar 23, 2012 at 3:09 PM, Sander Mak <sand...@gmail.com> wrote:
>
> This is where organizations like the Apache Software Foundation are
> helpful. Apache frowns upon projects that don't make releases every so
> often, so you're likely to have a somewhat recent release of an apache
> product. It's up to you and your dependent software projects to ensure
> you're using the later releases.
Really? For instance, Apache Batik latest release (1.7) is from Jan 2008,
AFAIK (even though I see commits up to nine months ago):
http://xmlgraphics.apache.org/batik/download.cgi
> But in the end, we can't rely on Maven, Nexus, Apache, nor anyone else
> to do our due diligence for us. If our project includes a few dozen
> jars pulled in from who knows where (as do most) we must check the
> provenance of the bits we're including. Who does that? I know I don't
> do that enough.
Premising that it's really an interesting thread, I don't think Maven (or
similar tools which auto-download dependencies) has got a specific
problem. If you build with And and download libraries in a manual mode,
you're experiencing the same risks. The problem, in fact, is downloading
stuff, not the way you do. At least Maven centralizes the process and you
can do something - I mean you can set up checks in a standard way for
everything you need, instead of being forced to manually e.g. check
fingerprints searching for reference values in hundreds of different
places. As Sander said, then it's up to you to do the due diligence.
--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
fabrizio...@tidalwave.it
http://tidalwave.it - http://fabriziogiudici.it
Sander Mak
On Friday, March 23, 2012 10:21:20 PM UTC+1, greddin wrote:
On Fri, Mar 23, 2012 at 3:09 PM, Sander Mak wrote:
> What do you guys do in practice to prevent this? Does anyone have real-life
> experience with such an attack?I think you raise some really good questions here, some that I've
thought about before, but skipped over because "I don't have time to
think about those things" :-)
This is where organizations like the Apache Software Foundation are
helpful. Apache frowns upon projects that don't make releases every so
often, so you're likely to have a somewhat recent release of an apache
product. It's up to you and your dependent software projects to ensure
you're using the later releases.
As an aside, do you know if Artifactory contains the PGP checking
feature that Nexus does? We've been using the open-source version of
Nexus and are in the process of switching to the pro version of
Artifactory.
Fabrizio Giudici
> Right, but that does not necessarily solve the distribution/verification
> problem. Another company I've run in to that can help curating OSS is
> BlackDuck (http://www.blackducksoftware.com/management-of-open-source),
> however I've yet to see it in practice anywhere.
BlackDuck product suite goes beyond mere verification of integrity, but
also takes care of issues such as IP management. For instance, you might
be sure that you're only using code which is released through the Apache
License and not the GPL because you want to avoid virality, as you've
manually or automatically checked all the licenses of all the used
artifacts. But this doesn't exclude that some lines of code of a certain
artifact licensed through ASF have been indeed copied from a GPL project
(let's see the Oracle vs Google example for an extreme case). BlackDuck
offers a service based on sophisticated code chunk analysis in order to
find out problems such as the one I've described.
Sander Mak
Fabrizio Giudici
> For anyone interested in this discussion, I also posted a follow-up on
> how
> to actually verify Maven dependencies
> http://branchandbound.net/blog/security/2012/08/verify-dependencies-using-pgp/
> The situation is pretty dire as you can see: none of the Maven based
> build
> tools integrate this verification into their workflow, so it's all manual
> (or use the commercial Nexus Pro repo manager).
propose could be as well used with a free Nexus installation, by having
the script running against the raw filesystem where Nexus stores stuff,
with a crontab. It's not the best approach, of course, but it's the first
automated solution that comes to my mind and provides actual protection.
The further step could be to provide those functions in a Maven plugin, so
everybody could at least run some security check on his own local repo.
Jan Goyvaerts
--
You received this message because you are subscribed to the Google Groups "Java Posse" group.To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.