[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54F4B8EE.90401@debian.org>
Date: Mon, 02 Mar 2015 19:24:30 +0000
From: Simon McVittie <smcv@...ian.org>
To: oss-security@...ts.openwall.com
Subject: Re: CVE request: Maven downloads JARs via HTTP
On 02/03/15 17:26, gremlin@...mlin.ru wrote:
> On 2015-03-02 17:34:55 +0100, Martin Prpic wrote:
>
> >>> "Maven Central can now be accessed via HTTPS. I think the
> >>> default configuration should be switched to use that, rather
> >>> than the current unsecured HTTP transport."
>
> >> Does it use any sort of package signing and signature
> >> verification?
>
> > Seeing as the patch only does s/http/https/,
>
> Obviously, that doesn't really help.
It's a start, at least... it tells you that this was a reply to your
request, made by someone controlling the corresponding private key for a
"valid" certificate for Maven Central's hostname. Whether that's enough
depends on your threat model.
If the attacker capabilities assumed by your threat model include "can
obtain arbitrary certs from a widely-trusted CA" or "has obtained Maven
Central's private key" then no, it doesn't help. Similarly, if the
attacker's capabilities include "can upload arbitrary packages to Maven
Central" (I assume there's some sort of access control so the author of
log4j can upload new log4j versions but not new Eclipse versions, or
whatever?) then it doesn't help.
However, if the attacker is assumed to be able to do neither of these
things (think "man-in-the-middle on the same coffee shop wifi as you"
rather than "the NSA") then this is enough.
An end-to-end integrity check from the original publisher to the
consumer would prevent more attacks, but would also be harder to deploy
(it requires action from each publisher, verification at each consumer,
and a way to determine whether publisher X is authorized to publish
package Y); protecting against trivial attacks is not as good as
protecting against sophisticated attacks, but seems considerably better
than not protecting against anything at all.
S
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.
