[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20150303203916.EB7683AE009@smtpvbsrv1.mitre.org>
Date: Tue, 3 Mar 2015 15:39:16 -0500 (EST)
From: cve-assign@...re.org
To: mprpic@...hat.com
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com
Subject: Re: CVE request: Maven downloads JARs via HTTP
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> I don't see a CVE assigned for this anywhere:
>
> https://jira.codehaus.org/browse/MNG-5672
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 repo.maven.apache.org web site was not
accessible via https, or at least not for free.
(http://web.archive.org/web/20140702132623/http://www.sonatype.com/clm/secure-access-to-central
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
http://repo.maven.apache.org 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
repo.maven.apache.org 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:
https://news.ycombinator.com/item?id=8101758 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, https://news.ycombinator.com/item?id=8100517 says "It's possible
to sign jars, but in my experimentation with standard tools, these
signatures aren't checked."
https://news.ycombinator.com/item?id=8101735 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
http://openwall.com/lists/oss-security/2014/06/26/5 post) but nobody
responded.
- --
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)
iQEcBAEBAgAGBQJU9hunAAoJEKllVAevmvmsNjAH/RiOr2s8Ne3KwnHUORo4g3Mc
kdQ5TkdVhpYqfmm4C5zfkXZYgvkA0pbkj3owoyQEq6EDUPEhx1bBAEyZ5GW6AUhA
2nKn7UCZNOOyDpvwbGEfTqw1jSg6lQHGpHeaCudXp6ypL05K4262C3Ei/ewQLFvm
Vwge7SifkFpT2YjSKMaYjNF8c2gU+CIMAcc4PIaujfsErx66c9I0JEkltJIyKH7J
WGM8meQvTj5GqEXHJvGswWqhZC+Y6kzjIB5MXk5GJZClzS0gvEt5vKVI0kimMmGc
fumBuNyBJTh9UVFjBc785R/+5Ee8HhebgFiVZh9Qljv0xnD3FJrQLcUhxvGsAYE=
=rpbn
-----END PGP SIGNATURE-----
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.
