How secure is using Maven?

问题:

What are the risks and possibilities or scenarios whereby someone sets up masquerades of maven repositories and/or ip streams to provide masqueraded library copies of the original but injected with malicious or harmful code.

What are the steps and practices to prevent such risks and possibilities?

回答1:

I suppose a dedicated and resourceful attacker could perform an MITM attack and intercept all requests to public Maven repositories, carefully injecting malicious bytecode into the JAR artifacts, then recalculating and supplying the SHA1 hashes.

To the client, it would appear as a legitimate artifact: the binary JAR and the SHA1 match and will be the same even if they check alternate mirrors.

I suppose the only real solution is to request the central repos to support HTTPS (and trust that TLS itself hasn't been broken).

Alternatively, a practical approach might be to set up a Maven proxy (Artifactory or Nexus) served over HTTPS to internal clients. This reduces the attack surface and means that you'll just have to secure the communication lines from that server to the outside world. I would periodically double check that the JARs and hashes on the proxy match those on the public mirrors using a totally independent, trusted network.

If you really, really want to be secure you wouldn't be trusting binaries—instead, you'd be downloading all source code and reviewing them by hand before compiling them yourself—but that assumes you have enough qualified resources and time to conduct the reviews and trust your entire build tool chain to begin with.

Well, security in layers as they always say.

回答2:

I can think of several scenarios, though the first isn't Maven-specific.

1. DNS cache poisoning

   The DNS data you use to get to the standard repositories could be poisoned, causing Maven to download artifacts from a different repository. See the wikipedia article on DNS cache poisoning.

2. Non-standard repositories

   Any repository you add to your Maven configuration could provide artifacts that include malicious code. Prevent this by using only those 3rd party repositories that you trust.

3. Repository poisoning

   Based on Maven's Guide to uploading artifacts to the Central Repository, it looks like the central Maven repository publishes artifacts from approved repository hosts, so security of artifacts depends on the host. I don't know specifics about the process of becoming an approved repository host, but with so few listed it's probably onerous.

   In addition, the central repo requires PGP signatures for all deployments, so unless a malicious user gains access to the private key for a project, I don't think this is possible.

4. Artifact modification during transmission (man in the middle)

   Maven does automatic checksum verification for all artifacts, so the attacker would have to modify the artifact and the accompanying checksums to inject malicious code. I don't know if you could prevent it completely, but to make sure you're paying attention to checksums, make sure your checksum policy isn't set to ignore. See the settings doc.

As other commenters have mentioned, a good way to prevent malicious code from getting into your production deployment is to only use an internal Maven repository for production release builds. By restricting access to the addition of dependencies to that repository, you can make sure that they are all verified at whatever level you choose, e.g. checksum double-checking, source scanning.

回答3:

If you use well-known repositories (central maven repository, jboss repository) it is very low possibility of injecting harmful code. Computer virus, your ISP, or ISP of your ISP to do so, must to mess in DNS servers, or change routing paths for some set of destinations. I think that's rather unlikely - the same is not only about maven repos but for all internet services (email, http, voip and so on). What's more the same risk is with downloading JARs directly from project sites.
Anyway, if you want to have a total control you can set up your own maven repository (http://nexus.sonatype.org/)

Every file available in the repository should have md5 or sha checksum generated - this way you can validate if what you downloaded is really what you wanted. But - if the attacker (virus) is smart enough to intercept your data transfer and mess in JAR files he will be also smart enough to intercept md5/sha checksums. The defense against it is to provide PGP signatures both for checksums and artifacts - release artifacts uploaded to central repo are forced to do so (.asc files)

The good idea is to use Nexus Professional - you would be able to configure procurement suite to check PGP signature against a public key server each time artifact is downloaded. More information about PGP signatures with maven can be found here:

https://docs.sonatype.org/display/Repository/How+To+Generate+PGP+Signatures+With+Maven

http://www.sonatype.com/people/2012/03/the-first-line-of-defense-checksums-and-pgp-signatures-in-repositories/