www-repository mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <steve.lough...@gmail.com>
Subject Re: Maven repository security
Date Tue, 01 Aug 2006 18:15:29 GMT
I had a look this morning; I can't do it again as docs.codehaus.org is
unreachable, so here is stome stuff from memory.

0. Its really hard to get things secure, because a single bug breaks
the security. Its not like normal code where bugs can be worked
around. You suddenly have to think about how to securely distribute
the initial app, the one with basic trust and auth built in, as that
becomes an attack point.

1. make sure that Ben Laurie overviews the spec too, as he is
effectively the apache security expert. I've also CC'd Antonio Laim,
who is the SmartFrog security police.

2. JAR signing -

We may want to add an apache CA in the distributions somehow, so that
we can trust apache signed JARs.

2a.
It's almost impossible to verify that a JAR is signed, because what is
really happening is every file entry in the archive is individually
signed. You need to pull apart the zip file and validate every
resource separately, and that is not built in to the Sun API (or
Ant's, BTW). You also need to pull down the JAR before doing the
validation; anything that does remote classloading is vulnerable to
post-validation attacks.

2b.
What is interesting about JARs is that multiple people can sign them,
and the signing doesnt affect the other signings, because nobody signs
the manifest. Actually, that's a possible attack point. I could edit
the Class-Path, Sealed: or Main: entries in a JAR and nobody would
notice until the thing ran.

2c.
What aftermarket signing JARs does do is break the SHA1 and MD5
checksums of the JAR itself. So I cannot sign JARs in my local maven
cache without their checksums changing, even though, as far is java is
concerned, they are still valid and signed.


3. post-installation attacks. There's an implicit attack point in the
maven local cache, as all files have known locations. If I gain access
to your filesystem I could insert a custom JAR in there. That may give
me privilege escalation if I know that, say, ehcache.jar gets copied
into JBoss/default/lib and then runs as root. We need something to
audit the JARs. I can't do that by signing all the JARs because of 2c,
and because of things like hibernate/cglib failing
[http://opensource.atlassian.com/projects/hibernate/browse/HHH-1365]

What might be interesting would be for a way for me to checksum all
artifacts in my own repo and sign the checksums, so that I can say
that yes, I trust them. Then the runtime could detect if something
different from my signing and bail out. This would let the ops teams
restrict artifact retrieval/loading to only approved artifacts, while
still using the common repository.

In this world I need a signature file for every artifact, one that
contains a list of signings of the checksum, and which can have extra
signatures appended to it without contaminating the artifact.

I might also need a way of publishing signatures from different repositories.

4. we need a way of revoking artifact authentications. it will happen,
let's plan for it.
-steve

On 01/08/06, Brett Porter <brett.porter@gmail.com> wrote:
> Hi,
>
> I'd be interested to get feedback on this early draft of possible ways
> to improve the verification of downloaded artifacts from Maven
> repositories to complete the implementation in the next couple of
> months.
>
> http://docs.codehaus.org/display/MAVEN/Repository+Security+Improvements
>
> Some of it still needs to be thought through some more... I've posted
> it to dev@maven.apache.org too so feel free to reply there or here
> (and I'll integrate any feedback into the document either way).
>
> Thanks,
> Brett
>

Mime
View raw message