Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue,  3 Mar 2015 15:39:16 -0500 (EST)
Subject: Re: CVE request: Maven downloads JARs via HTTP

Hash: SHA1

> I don't see a CVE assigned for this anywhere:

In many cases, security-related changes that a vendor characterizes as
an "Improvement" do not have CVE IDs:

  > Switch access to Maven Central to HTTPS
  > Type: Improvement
  > the Sonatype Operations team has coordinated certificates and other
  > setup with our excellent CDN provider Fastly and you can now all
  > enjoy the content of the Central Repository via HTTPS/SSL.

This suggests that, at the time that the default configuration was
shipped for 3.2.2, the web site was not
accessible via https, or at least not for free.
suggests that https was available for $10.) Given that that is what
existed, we don't feel that there is a clear answer to the question of
whether Maven should have refused to access URLs or whether it should have accepted
the risk of man-in-the-middle attacks. Neither answer would be
inherently a "mistake." At least some deployments of Maven are on
relatively secure networks at software-development companies, where
man-in-the-middle attacks are relatively difficult and/or infrequent.
Installation of Maven on a portable machine that is commonly connected
via public Wi-Fi is not the prevailing use case.

(The question on the other side, specifically whether should ever have been deployed with its former
configuration, is site-specific and is outside the scope of CVE. Note
that this was apparently intentional: says "The reality is that
prior to moving to a CDN, it was going to be pretty intensive to offer
SSL on the scale of traffic we were seeing. The priority at that time
was ensuring higher availability.")

Also, says "It's possible
to sign jars, but in my experimentation with standard tools, these
signatures aren't checked." says "Signatures have
been required on Central for years and there are tools to verify them,
including repository managers." MITRE has not researched whether any
version of Maven was able to download and use a signed file, and could
have checked the signature but did not actually implement signature
checking. There is a possibility of one or more CVE IDs if anyone has
identified a corresponding Maven code problem or fix.

To summarize, we don't think it's currently worthwhile to assign CVE
IDs for all cases in which any product obtains code from an http
endpoint and could then conceivably execute that code. There are MANY
such cases. As in the above Central Repository example, existence of
http endpoints can be intentional, and the world hasn't transitioned
to a state where everyone believes that http is always wrong. We've
asked about this previously here (see the end of the post) but nobody

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through ]
Version: GnuPG v1.4.14 (SunOS)


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.