We often joke about 'Maven downloading the internet', but how often are we concerned about what is actually downloaded? I've written some thoughts (http://branchandbound.net/blog/security/2012/03/crossbuild-injection-...) on cross-build injection attacks, where malicious code could be injected into a build.
What do you guys do in practice to prevent this? Does anyone have real-life experience with such an attack?
On Fri, Mar 23, 2012 at 3:09 PM, Sander Mak <sander...@gmail.com> 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.
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.
On Fri, 23 Mar 2012 22:21:20 +0100, Greg Reddin <gred...@gmail.com> wrote: > On Fri, Mar 23, 2012 at 3:09 PM, Sander Mak <sander...@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):
> 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.
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" :-)
Right, that sounds all too familiar :)
> 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.
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.
> 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.
I'm not sure, but a cursory glance through Google did not turn up any supporting evidence...
On Mon, 26 Mar 2012 12:01:27 +0100, Sander Mak <sander...@gmail.com> wrote: > 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.
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).
On Friday, March 23, 2012 9:09:02 PM UTC+1, Sander Mak wrote:
> We often joke about 'Maven downloading the internet', but how often are we > concerned about what is actually downloaded? I've written some thoughts ( > http://branchandbound.net/blog/security/2012/03/crossbuild-injection-...) > on cross-build injection attacks, where malicious code could be injected > into a build.
> What do you guys do in practice to prevent this? Does anyone have > real-life experience with such an attack?
On Wed, 22 Aug 2012 09:59:11 +0200, Sander Mak <sander...@gmail.com> wrote:
> 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-u... > 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).
Very valuable stuff, Sander. I think that the scripting solution you
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.
> Very valuable stuff, Sander. I think that the scripting solution you
> 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.
> --
> You received this message because you are subscribed to the Google Groups
> "Java Posse" group.
> To post to this group, send email to javaposse@googlegroups.com.
> To unsubscribe from this group, send email to javaposse+unsubscribe@**
> googlegroups.com <javaposse%2Bunsubscribe@googlegroups.com>.
> For more options, visit this group at http://groups.google.com/** > group/javaposse?hl=en <http://groups.google.com/group/javaposse?hl=en>.
