www-repository mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Kriens <Peter.Kri...@aQute.biz>
Subject Re[2]: Maven repository security
Date Wed, 02 Aug 2006 07:30:43 GMT
0. A single bug breaks security, no work arounds
   I think this is the hallmark of a good security system?

2. A CA would be really good, but note that there is a horrible
   authorization problem. How can a central person/group be
   responsible for all Apache code? You might want to think if a
   delegated CA. Each project lead would own a certificate that is
   signed by an Apache certificate. However, if you want to be trusted
   by root certificates, you would need a special Apache certificate
   that can be used to sign other signing certificates. Maybe in this
   case you can set a standard and use a self signed certificate.
   Anyway, the hardest problem is the trust problem. Which works both
   ways. Can users trust the certificate, and can the signer trust
   the code he signs? Before you do anything else, work out the trust
   model. Who will do what and trust what and when. The rest is mechanics

2a. JAR file verification
   Verifying a JAR file is not that hard as it sounds. Jarsigner can
   do it, and it is not that hard to code up. However, why do you need to
   do this? The class loader will do this properly during class loading
   which gives you end-to-end security. Notice that a signed JAR does
   not tell you it is trustworthy, it just tells you who signed it.
   You need to decide how much you trust the signer (or the signer of
   the signer certificate if you use certificate chains).

   If you do not use JARs (e.g. remote classloading) you obviously do not
   get the advantages of signing because it is a JAR mechanism.

2b. Not signing the manifest
   The manifest is nowadays signed. The way signing works is that each
   signer creates a manifest like file that contains hashes of
   relevant parts of the manifest. This file is then digitally signed
   using one of the signing algorithms. This manifest like file can
   also hold a hash of the global section (where you have your
   Class-Path or Sealed attributes).

2c. Checksumming JARs
This has lots of complications because you get multiple files. JAR
signing is really very powerful when you get the hang of it. And it
has the GREAT advantage you only have a single file to worry about.
And it is built into all VMs.

3. Signing the JAR checksums
The power of signing is that you create a delegated trust model which
does not require a bottleneck. The problem is that signing was only
partially intended to check the integrity of the JAR. The key part is
that it allows you to verify that the the signer can be trusted
without having to know all signers a priori. Using Java security, you
can even place each class in its own sandbox depending on the
certificate (if you want to go ballistic).

The idea is that anybody can fool with your caches, transport or
whatever because the VM checks the signature and puts the classes in
the pre-assigned sandbox (which can be an empty sandbox). This
end-to-end security over an untrusted network works usually better
than trying to secure the whole chain.

Using signing without Java permissions is not very useful btw.

---
There are also some other issues. One thing we found in the OSGi
Alliance is that if you do not sign EACH resource in the JAR there are
some corner cases that can be used to exploit. Another thing we found
is that for a trust model to work you need something finer that
sandboxes; we added a permission file to a bundle. If you are
interested, there is a section about these issues in the OSGi R4 spec.

Security is really hard, maybe the current Java security model is not
really matching your needs. However, shortcuts because you need all of
it is often causing regrets later down the line. I am not a big fan of
the Java 2 security model (of which signing is a part). However,
whenever I use a Java VM, a big part of that thing is spending doing
Java security things. Trying to devise alternatives is wasting those
CPU cycles which I really do not want to worsen by adding my own
mechanisms. And getting it right is really, really hard.

Kind regards,

     Peter Kriens





SL> I had a look this morning; I can't do it again as docs.codehaus.org is
SL> unreachable, so here is stome stuff from memory.

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

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

SL> 2. JAR signing -

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

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

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

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


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

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

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

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

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

SL> 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
>>

-- 
Peter Kriens                              Tel +33467542167
9C, Avenue St. Drézéry                    AOL,Yahoo: pkriens
34160 Beaulieu, France                    ICQ 255570717
Skype pkriens                             Fax +1 8153772599


Mime
View raw message