13 ms·

How to take over the computer of a Maven Central user

405 points by akerl_ 12y ago

akerl_ 12y ago
It's not specifically named in the article, but the software shown with the firewall popup is Little Snitch, and it's great: http://www.obdev.at/products/littlesnitch/index.html http://www.obdev.at/products/littlesnitch/index.html
finnn 12y ago
Evilgrade (https://github.com/infobyte/evilgrade https://github.com/infobyte/evilgrade) is a similar tool that works on a wider variety of insecure updaters. Perhaps a module could be written? Maybe one already exists, I haven't played with it in a while
moxie 12y ago
At Open Whisper Systems, we wrote a small open source gradle plugin called "gradle-witness" for this reason. Not just because dependencies could be transported over an insecure channel, but also because dependencies could be compromised if the gradle/maven repository were compromised: https://github.com/whispersystems/gradle-witness https://github.com/whispersystems/gradle-witness It allows you to "pin" dependencies by specifying the sha256sum of the jar you're expecting.
- shortstuffsushi 12y ago
  That's interesting, doesn't Maven offer a checksum option to begin with? I feel like just the other day, someone was saying "who ever uses checksums anyway," but a package manager run over insecure methods seems like the perfect time to do so.
  - mike_hearn 12y ago
    For bitcoinj we developed a similar plugin for Maven: https://github.com/gary-rowe/BitcoinjEnforcerRules https://github.com/gary-rowe/BitcoinjEnforcerRules
  - yourad_io 12y ago
    From the article: > When JARs are downloaded from Maven Central, they go over HTTP, so a man in the middle proxy can replace them at will. It’s possible to sign jars, but in my experimentation with standard tools, these signatures aren’t checked. The only other verification is a SHA1 sum, which is also sent over HTTP.
    - shortstuffsushi 12y ago
      I agree that they aren't checked by default, you'd need to implement it (as the parent commenter seemed to be doing with their gradle plugin). Regarding the sums being sent over HTTP as well, seems that you'll need a checksum for your checksum. Ultimately, though, it just seems that it'd be best to avoid this while it's over HTTP.
- notthetup 12y ago
  This! I am totally happy donating $10 to whisper systems for this work instead of forcing me to donate $10 to Apache Foundation (although a worthy cause) to be able to get https access to Maven Central.
  - moxie 12y ago
    Thanks! You can support ongoing development by sending donations to our BitHub. Anyone who commits to an Open Whisper Systems repository will get 2% of your donation: https://whispersystems.org/blog/bithub/ https://whispersystems.org/blog/bithub/ The dashboard: http://bithub.whispersystems.org/ http://bithub.whispersystems.org/
- heavenlyhash 12y ago
  Hi moxie, might I ask if you've considered SHA-384 instead? If I understand correctly, SHA-256 is part of the SHA-2 family of hash algorithms, and like SHA-1, when used alone it is subject to length extension attacks. SHA-384 is also a member of the SHA-2 algorithm family, but is immune to length extension attacks because it runs with an internal state size of 512 bits -- by emitting fewer bits than its total internal state, length extensions are ruled out. (Wikipedia has a great table for clarifying all these confusing names and families of hashes: [5].) Other hashes like BLAKE-2 [1], though young, also promise built-in immunity to length-extension attacks. mdm [2] is immune to this because the relevant git datastructures all include either explicit field lengths as a prefix, or are sorted lists will null terminators, both of which diffuse length extension attacks by virtue of breaking their data format if extended. Not that it's by any means easy to find a SHA-256 collision at present; but should collisions be found in the future, a length extension attack will increase the leverage for using those collisions to produce binaries that slip past this verification. An md5 Collision Demo[3] by Peter Selinger is my favourite site for concretely demonstrating what this looks like (though I think this[4] publication by CITS mentions the relationship to length extension more explicitly). (I probably don't need to lecture to you of all people about length extensions :) but it's a subject I just recently refreshed myself on, and I wanted to try to leave a decent explanation here for unfamiliar readers.) -- I'm also curious how you handled management of checksums for transitive dependencies. I recall we talked about this subject in private back in April, and one of the concerns you had with mdm was the challenge of integrating it with existing concepts of "artifacts" from the maven/gradle/etc world -- though there is an automatic importer from maven now, mdm still requires explicitly specifying every dependency. Have you found ways to insulate gradle downloading updates to plugins or components of itself? What happens when a dependency adds new transitivity dependencies? I guess that's not a threat during normal rebuilds, since specifying hashes ahead of time already essentially forbids loosely semver-ish resolution of dependencies at every rebuild, but if it does happen during an upgrade, does gradle-witness hook into gradle deeply enough that it can generate warnings for new dependencies that aren't watched? This plugin looks like a great hybrid approach that keeps what you like from gradle and while starting to layer on "pinning" integrity checks. I'll recommend it to colleagues building their software with gradle. P.S. is the license on gradle-witness such that I can fork or use the code as inspiration for writing an mdm+gradle binding plugin? I'm not sure if it makes more sense to produce a gradle plugin, or to just add transitive resolution tools to mdm so it can do first-time setup like gradle-witness does on its own, but I'm looking at it! -- Edited: to also link the wikipedia chart of hash families. -- [1] https://blake2.net/ https://blake2.net/ [2] https://github.com/polydawn/mdm/ https://github.com/polydawn/mdm/ [3] http://www.mscs.dal.ca/~selinger/md5collision/ http://www.mscs.dal.ca/~selinger/md5collision/ [4] http://web.archive.org/web/20071226014140/http://www.cits.rub.de/MD5Collisions/ http://web.archive.org/web/20071226014140/http://www.cits.ru... [5] https://en.wikipedia.org/wiki/SHA-512#Comparison_of_SHA_functions https://en.wikipedia.org/wiki/SHA-512#Comparison_of_SHA_func...
- jwn 12y ago
  Cool, but am I right that it requires that you trust the jar dependency you have initially on your local filesystem?
wernerb 12y ago
This is indeed a problem that needs to be addressed at some point. The MITM possibility has been mentioned before at SE http://stackoverflow.com/questions/7094035/how-secure-is-using-maven http://stackoverflow.com/questions/7094035/how-secure-is-usi...
jontro 12y ago
This is a horrible policy made by sonatype. A better alternative of mavencentral should be created...
- einrealist 12y ago
  It is not the fault of Sonatype. We should not trust Central right away. If I worry about malicious artifacts from Central, I must host my own repository and manage artifacts myself. And that way, I can just map other repositories I trust more.
  - lmm 12y ago
    Trusting Central > Trusting everyone on the network path between you and central.
MrSourz 12y ago
I'm torn on how I feel about security being a paid feature in this case. Here the onus is being placed on the user, yet many won't be conscious of the choice they're making. The tiff mentioned in the article was interesting to read. > https://twitter.com/mveytsman/status/491298846673473536 https://twitter.com/mveytsman/status/491298846673473536
- homulilly 12y ago
  There's two problems with this that I see. The first is, as you said, that a lot of people won't even realize they need to pay for secure downloads. I also feel like in the case of something like a package manager, this potentially harms the wider community in ways that charging for features in a specific piece of software doesn't.
  - technomancy 12y ago
    Technically paying for an auth token is not sufficient. The token cannot be used directly by Maven or Leiningen, but only by a Nexus proxying repository manager. Not a big deal if you work at a professional Clojure shop, but a huge hassle if you're freelance or just getting started.
  - sitkack 12y ago
    It is like having a population partially vaccinated, almost pointless on a large scale.
femto113 12y ago
Perhaps as a stopgap Maven Central (or a concerned third party?) could publish all of the SHA1 hashes on a page that is served via HTTPS. This would at least allow tools to detect the sort of attack described in the article.
jc4p 12y ago
jCenter is the new default repository used with Android's gradle plugin, I haven't used it myself yet but it looks like the site defaults to HTTPS for everything: https://bintray.com/bintray/jcenter https://bintray.com/bintray/jcenter
- sgarman 12y ago
  Thanks for pointing this out, this is REALLY new, perhaps added in the most recent build. I didn't see notes for this either.
  - jc4p 12y ago
    Yeah, my new projects from Android Studio Beta (released at I/O) use it as the default which was super confusing at first since I didn't see any release notes regarding it.
- tdicola 12y ago
  Nice, I was going to ask if maybe Google or someone invested heavily in Android could step up and provide a secure source of dependencies for everyone.
- jbaruch_s 12y ago
  Full disclosure - I am a developer Advocate with JFrog, the company behind Bintray. So,jcenter is a Java repository in Bintray (https://bintray.com/bintray/jcenter https://bintray.com/bintray/jcenter), which is the largest repo in the world for Java and Android OSS libraries, packages and components. All the content is served over a CDN, with a secure https connection. JCenter is the default repository in Goovy Grape (http://groovy.codehaus.org/Grape http://groovy.codehaus.org/Grape), built-in in Gradle (the jcenter() repository) and very easy to configure in every other build tool (maybe except Maven) and will become even easer very soon. Bintray has a different approach to package identification than the legacy Maven Central. We don't rely on self-issued key-pairs (which can be generated to represent anyone, actually and never verified in Maven Central). Instead, similar to GitHub, Bintray gives a strong personal identity to any contributed library. If you really need to get your package to Maven Central (for supporting legacy tools) you can do it from Bintray as well, in a click of a button or even automatically. Hope that helps!
akerl_ 12y ago
Thanks to whomever changed the title; I didn't like the original title, but couldn't come up with a better accurate one.
tensor 12y ago
The biggest problem with this policy is that new users, or even experienced ones, are likely not aware of it. This is a very serious problem that should be addressed quickly. edit: and with websites everywhere routinely providing SSL, it seem crazy that it has to be a paid feature for such a critical service.
- sitkack 12y ago
  Funny thing is that CERT doesn't have a problem with shenanigans like this. They are more concerned with buffer overflows than by-design stupidity.
avz 12y ago
Exposing your users to MITM attacks in order to encourage donations? Pure evil.
- ternaryoperator 12y ago
  That's a little paranoid. Let's see, we'll completely ruin our rep and our core business activity just so you're forced to donate--not to us, but to this open source group over here. Dude, put down the pipe.
  - shawnz 12y ago
    Isn't it exactly what they are doing, though? The only reason you would want HTTPS is to prevent MITM attacks. By making it a premium feature, they are making MITM attack mitigation a premium feature.
- danielweber 12y ago
  If you aren't paying money, you aren't the user, you are a product. Freemium models often suck because of stuff like this[1]. But if the "users" would just consider it normal to pay money then we wouldn't have crazy things going on where people providing critical infrastructure services need to figure out how to "convert" their "users." Instead, say, every professional Java shop would pay $100 a year or so for managed access. Projects that want to use it like a CDN so their users could download would pay a fee to host it. They have bills to pay. They'll cover them one way or the other. If we pay directly at least we know what the game is. [1] They could be inserting advertising into the jars. Hey, at least it would still be a "free" service, right?
- deleted 12y ago
  [deleted]
clarkm 12y ago
So in principle, it's doing the same thing as: $ curl http://get.example.io | sh which we all know is bad. But in this case, it's hidden deep enough that most people don't even know it's happening.
- akerl_ 12y ago
  Sort-of. That has the additional non-malicious risks. A broken connection turns "rm -r /var/lib/cool/place" into "rm -r /var/" and the shell processes that.
  - technomancy 12y ago
    It's also different in that the artifact signatures are there for you to check if you want to; it's just that most people don't bother, and even if you do, you probably can't tell which keys you should trust to begin with.
- yonran 12y ago
  Downloading from HTTP is not an issue (as far as integrity is concerned) if maven were to validate the downloads against some chain of trust. But apparently it is not. Now I am wondering what tool actually uses those .asc files that I have to generate using mvn gpg:sign-and-deploy-file when I upload new packages to sonatype...
  - technomancy 12y ago
    Running `lein deps :verify` does this.
    - brl 12y ago
      How does it know what the correct signing key is? edit: Looked up answer myself. Lein downloads whatever key the signature claims to be made with from public keyservers. How does this provide any additional security over not bothering to verify signatures?
sitkack 12y ago
luarocks has the same problem. You don't need SSL, you need the packages to be signed.
technomancy 12y ago
For Leiningen at least the goal is eventually to be able to flip a switch that will make it refuse to operate in the presence of unsigned dependencies. We're still a ways away from that becoming a reality, but the default is already to refuse to deploy new libraries without an accompanying signature. Edit: of course, the question of how to determine which keys to trust is still pretty difficult, especially in the larger Java world. The community of Clojure authors is still small enough that a web of trust could still be established face-to-face at conferences that could cover a majority of authors. The situation around Central is quite regrettable though.
- weavejester 12y ago
  Leiningen also uses Clojars over HTTPS by default, I believe, so even without a web of trust, Clojars is still more secure than Central.
  - technomancy 12y ago
    Technically true, but practically this doesn't mean anything. No one uses Clojars on its own, so if an attacker were able to perform a MITM attack, they could inject a spoofed library into the connection to Central even if the library should be fetched from Clojars.
pjlegato 12y ago
All of Maven central is only 180gb, according to https://maven.apache.org/guides/mini/guide-mirror-settings.html https://maven.apache.org/guides/mini/guide-mirror-settings.h... How hard would it be to just mirror it to S3 and use it from there via HTTPS?
- technomancy 12y ago
  > How hard would it be to just mirror it to S3 and use it from there via HTTPS? Trivial. Now ask: how hard would it be to pay the bandwidth charges, assuming it were a public bucket. I don't know the answer, but it's a much more interesting question.
  - cordite 12y ago
    I am guessing with Amazon, even though they run Java, they wouldn't do it out of the good of their hearts.
  - pjlegato 12y ago
    Yes, a very interesting question. It'd be very expensive. It occurs to me that BitTorrent technically solved the problem of high bandwidth costs long ago; millions of people transfer 1.1TB files around every day without worrying about bandwidth costs at all. Can we come up with a similar system for jars? Why are we still relying on central servers for this at all?
- teraflop 12y ago
  That text was last updated in 2010; currently the repository is about 1.1TB. http://search.maven.org/#stats http://search.maven.org/#stats
  - pjlegato 12y ago
    Ack! This does not do anything to increase my confidence in the Maven project's guardianship of our collective security.
iancarroll 12y ago
What firewall is that? Looks nice.
- MBlume 12y ago
  http://www.obdev.at/products/littlesnitch/index.html http://www.obdev.at/products/littlesnitch/index.html
dandelany 12y ago
Sorry to nitpick, but you might wanna fix this typo: s/pubic/public :)
0x0 12y ago
I wonder how many enterprise apps have been backdoored through this flaw over the years by now.
- sitkack 12y ago
  I'd immediately backdoor the rt.jar and the compiler so that future binaries have the backdoor. Trusting trust ...
abalone 12y ago
I understand the need to raise money for projects, but the attitude[1] that security is an optional "premium" feature needs to end. It should be no different from shipping broken code. You can't just say, "oh, well we offer a premium build that actually works, for users that want that." Everybody needs it. Evernote made this mistake initially when SSL was originally a premium feature. They fixed it. Granted, there are degrees of security but protection from MITM attacks is fundamental. (Especially for executable code!) [1] https://twitter.com/mveytsman/status/491298846673473536 https://twitter.com/mveytsman/status/491298846673473536 UPDATE: @weekstweets just deleted the tweet I was referencing where he described security as a premium feature "for users who desire it" or words to that effect.
- gregso 12y ago
  But will users in aggregate pay more when extra effort and resources are expended on security? Will you? If the answer is no, then the smart developer has no financial incentive to do so, and every reason to segment security out as a premium feature. Maybe MITM vulnerability counts as broken code. But as always, markets win. I don't think the status quo will change until users consider security assurances worth hard dollars.
  - tdicola 12y ago
    Good luck getting your users to come back and trust you after a major security incident that compromises their systems. I would turn it around and think of it this way, is it worth giving up some profit to help ensure you don't have embarrassing and damaging security issues? It's like insurance, you pay the premium and hope you never need it.
    - danielweber 12y ago
      If they aren't paying you, they aren't your users. This reinforces my priors that there is very little "free-as-in-beer" software.
      - 12y ago
GaryRowe 12y ago
I wrote a Maven plugin to avoid this. It's available under MIT licence: https://github.com/gary-rowe/BitcoinjEnforcerRules https://github.com/gary-rowe/BitcoinjEnforcerRules
passive 12y ago
For those of you in the Python world concerned about such a thing, check out Peep: https://pypi.python.org/pypi/peep https://pypi.python.org/pypi/peep It's a pip wrapper that expects you to provide hashes for your dependencies in requirements.txt. There was a lightning talk at PyCon this year, it seems super easy to use (though admittedly I'm not using it regularly yet).
jnbiche 12y ago
npm has the same problem of sending packages over http, but it's even worse since on average each node package uses about a billion other packages and because injecting malicious code in JavaScript is incredibly easy. And to be clear, just http here is not the issue. It's http combined with lack of package signing. apt runs over http, but it's a pretty secure system because of its efficient package signing. Package signing is even better than https alone since it prevents both MITM attacks and compromise of the apt repository. In fact, apt and yum were pretty ahead of their time with package signing. It's a shame others haven't followed their path.
- seldo 12y ago
  npm by default uses HTTPS, and has for more than 3 years. It's a little confusing because the loglines all say "http" in green, but if you actually look at the URLs being downloaded they are all to https://registry.npmjs.org/ https://registry.npmjs.org/
jgalt212 12y ago
> When can this happen? If you ever use a public wifi network in a coffee shop Just don't do this. There is no such thing as a free lunch (or wifi).
- andrewchambers 12y ago
  The NSA will proxy anyone they feel like.
- graue 12y ago
  I do it. I always thought, "What's the harm? Everything important is over SSL these days". Apparently not!
fiatmoney 12y ago
So if they need some money, what is a better revenue model for them? - charge some token amount of money to projects (harms the ecosystem, probably not a good idea) - charge some amount for projects to host old versions, or for users to access old versions (same idea as the first, just less so) - charge for access to source jars - paid javadoc hosting - rate-limiting for free users (the "file locker" model; particularly effective at convincing people sharing an office IP into paying up) Any others?
- ontoillogical 12y ago
  They claim the money is a donation to a open source software project, so they don't even need the money.
chetanahuja 12y ago
If I understand this correctly, maven based builds can contain dependencies on libraries hosted on remote servers. golang build system has (or had) something similar too. Witnessing this trend take hold is astonishing and horrifying in equal parts. Not just as a security problem (which is clearly obvious) but also a huge hole in software engineering practices. How can anyone run a production build where parts of your build are being downloaded from untrusted third party sources in real time? How do you ensure repeatable, reliable builds? How do you debug production issues with limited knowledge of what version of various libraries are actually running in production?
- dmacvicar 12y ago
  Java developers kind of laugh when I explain them that Linux distros struggle to bootstrap Maven from source due to being a non-trivial tool that depends on hundreds of artifacts to build. The point is, what do you care that your repo is local, or that your jars are secured, if the tool you got maven itself in binary form, from a server you don't control? That is the whole point of Linux distros package managers. It is not only about dependencies. Is about securing the whole chain and ensure repeatability. Maven design, unlike ant, forces you to bootstrap it from binaries. Even worse, maven itself can't handle building a project _AND_ its dependencies from source. Why will the rest of the infrastructure be important then? Yes, Linux distros build gcc and ant using a binary gcc and a binary ant. But it is always the previous build, so at some point in the chain it ends with sources and not with binaries. And this is not about Maven's idea and concept. If it had depended on a few libraries and a simple way of building itself instead of needing the binaries of half of the stuff it is supposed to build in the first place (hundreds), just to build itself.
  - lmm 12y ago
    > Yes, Linux distros build gcc and ant using a binary gcc and a binary ant. But it is always the previous build, so at some point in the chain it ends with sources and not with binaries. I don't think so. The first versions of GCC were built with the C compilers from commercial UNIX from AT&T or the like. The first Linux systems were cross-built under Minix. At some point you'll go back to a program someone toggled in on the front panel, but we don't have the source for all the intermediate steps, nor any kind of chain of signatures stretching back that far. > And this is not about Maven's idea and concept. If it had depended on a few libraries and a simple way of building itself instead of needing the binaries of half of the stuff it is supposed to build in the first place (hundreds), just to build itself. Any nontrivial program should be written modularly, using existing (and, where necessary, new) libraries. Having a dependency manager to help keep track of those is a good thing. I don't see that it makes the bootstrap any more "binary"; gcc is built with a binary gcc for which source is available. Maven is built with a binary maven and a bunch of binary libraries, source for all of which is available.
deleted 12y ago
[deleted]
brianefox 12y ago
The project to offer ssl free to every user of Maven Central is already underway. Stay tuned for details.
- needusername 12y ago
  I'm pretty surprised that this article is news. Sonatype has been open about SSL for Maven Central since there has been Nexus or maybe even longer. I remember Jason van Zyl talking about this seven or more years ago.
- ontoillogical 12y ago
  Author here. Brian are you speaking as a representative of Sonatype, or are you a 3rd party?
  - brianefox 12y ago
    As a representative of Sonatype. The reality of cross build injection has been discussed for many years, I even linked to an XBI talk in my blog post announcing the availability of SSL. 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 and providing multiple data centers with worldwide loadbalancing. On our first CDN provider, they could not perform SSL certificate validation and thus were themselves susceptible to a MITM attack. So the decision at that point was to run SSL off of the origin server. We wanted to make it essentially free but wanted to ensure that the bandwidth was available for those that cared to use it, hence the small donation. The situation is different today with our new CDN, they can validate the certificates all the way through and that's how we intend to deploy it. We won't be able to enable full https redirections for all traffic since this would cause havok in organizations that are firewall locked and for tools that don't follow redirects. Each tool would need to adopt the new url. I've already suggested this change occur in Maven once we launch.
    - hrjet 12y ago
      I am not familiar with Sonatype and what relation it has with maven, but have you considered adding BitTorrent protocol to maven? This might help reduce traffic considerably.
foo-licious 12y ago
It's java who cares?
jimrandomh 12y ago
My main experience with Maven has been downloading some source code, and having to use Gradle to compile it. It went and downloaded a bunch of binaries, insecurely. There were no actual unsatisfied dependencies; it was just downloading pieces of Gradle itself. I would've much rather had a Makefile. Build scripts and package managers need to be separate.
- dmacvicar 12y ago
  Finally someone who sees the real problem.
- yourad_io 12y ago
  > Build scripts and package managers need to be separate. This. Especially when there's broken links, you're gonna have a bad (and long) time.
- taeric 12y ago
  I will join the small chorus agreeing that build scripts and package managers should be separate. Most folks I work with disagree. Curious if anyone knows of any well done takes on this. In either way. (If I'm actually wrong, I'd like to know.) (I fully suspect there really is no "right" answer.)
joncp 12y ago
The problem goes deeper. That firewall (Little Snitch) updates itself over port 80, so most likely unencrypted.
heavenlyhash 12y ago
SSL would have partially mitigated this attack, but it's not a full solution either. SSL is transport layer security -- you still fully trust the remote server not to give you cat memes. What if this wasn't necessary? Why can't we embed the hash of the dependencies we need in our projects directly? That would give us end-to-end confidence that we've got the right stuff. This is exactly why I built mdm[1]: it's a dependency manager that's immune to cat memes getting in ur http. Anyone using a system like git submodules to track source dependencies is immune to this entire category of attack. mdm does the same thing, plus works for binary payloads. Build injection attacks have been known for a while now. There's actually a great publication by Fortify[2] where they even gave it a name: XBI, for Cross Build Injection attack. Among the high-profile targets even several years ago (the report is from 2007): Sendmail, IRSSI, and OpenSSH! It's great to see more attention to these issues, and practical implementations to double-underline both the seriousness of the threat and the ease of carrying out the attack. Related note: signatures are good too, but still actually less useful than embedding the hash of the desired content. Signing keys can be captured; revocations require infrastructure and online verification to be useful. Embedding hashes in your version control can give all the integrity guarantees needed, without any of the fuss -- you should just verify the signature at the time you first commit a link to a dependency. [1] https://github.com/polydawn/mdm/ https://github.com/polydawn/mdm/ [2] https://www.fortify.com/downloads2/public/fortify_attacking_the_build.pdf https://www.fortify.com/downloads2/public/fortify_attacking_...
- michaelt 12y ago
  Why can't we embed the hash of the dependencies we need in our projects directly? There's a lot of stuff in Maven, like the versions plugin and the release plugin, to update dependencies to the latest version. This stuff is useful for continuous integration and automated deployment, especially when your project is split into lots of modules to allow code reuse. With code signing, you can (or hypothetically could, I don't know if anyone does this) check the latest version is signed by the same key as the previous version - whereas just pinning the hash wouldn't allow that. I agree pinning the hash is useful if the signing key is captured.
  - 12y ago
qwerta 12y ago
We store jars in git repo...
buckey 12y ago
Yeah have you ever wrote code on the play platform? There is your proof of concept at least on earlier versions static injection using annotations ... It's also how spring works and almost all dynamic ... Hell you can jit your code don't even need to compile it into a class the run time can do it for you ... That why I always compile my jar files so they can't be read as a compressed file anyway pretty cool sounds like you could have a lot of fun with someone doing this ... You could turn there computer into anything you want using Java command line functionality .... I.e. System.get(os.name) if windows do this if OS X do this if lunix do this using Java.lang.runtime.exec then after you open the back door to there computer time for socket connections and getoutputstream etc... Anyway point being java is a cross platform lang so there is a world of possibilities and most of the time they are running this from an IDE so if you inject a sudo call who knows what could happen
SanderMak 12y ago
The vulnerability even has a name: Cross-build injection attacks. I wrote about it some time ago [1], [2]. The complete answer includes verifying the (now mandatory) PGP signatures [3] of artifacts in Maven Central. But you need a web-of-trust for that and the whole process is rather impractical currently. [1] http://branchandbound.net/blog/security/2012/03/crossbuild-injection-how-safe-is-your-build/ http://branchandbound.net/blog/security/2012/03/crossbuild-i... [2] http://branchandbound.net/blog/security/2012/10/cross-build-injection-in-action?src=archive http://branchandbound.net/blog/security/2012/10/cross-build-... [3] http://branchandbound.net/blog/security/2012/08/verify-dependencies-using-pgp/ http://branchandbound.net/blog/security/2012/08/verify-depen...
- tomjen3 12y ago
  Instead of going WOT, why not just get a specific SHA hash, instead of a specific version?
  - SanderMak 12y ago
    Sure, you could obtain a hash out-of-band and pin to that. Not much more convenient given you have to do it for all transitive dependencies and Maven-plugin dependencies as well.

405 points by akerl_ 12y ago

It's not specifically named in the article, but the software shown with the firewall popup is Little Snitch, and it's great: http://www.obdev.at/products/littlesnitch/index.html http://www.obdev.at/products/littlesnitch/index.html

finnn 12y ago

Evilgrade (https://github.com/infobyte/evilgrade https://github.com/infobyte/evilgrade) is a similar tool that works on a wider variety of insecure updaters. Perhaps a module could be written? Maybe one already exists, I haven't played with it in a while

moxie 12y ago

At Open Whisper Systems, we wrote a small open source gradle plugin called "gradle-witness" for this reason. Not just because dependencies could be transported over an insecure channel, but also because dependencies could be compromised if the gradle/maven repository were compromised: https://github.com/whispersystems/gradle-witness https://github.com/whispersystems/gradle-witness It allows you to "pin" dependencies by specifying the sha256sum of the jar you're expecting.

shortstuffsushi 12y ago
That's interesting, doesn't Maven offer a checksum option to begin with? I feel like just the other day, someone was saying "who ever uses checksums anyway," but a package manager run over insecure methods seems like the perfect time to do so.
- mike_hearn 12y ago
  For bitcoinj we developed a similar plugin for Maven: https://github.com/gary-rowe/BitcoinjEnforcerRules https://github.com/gary-rowe/BitcoinjEnforcerRules
- yourad_io 12y ago
  From the article: > When JARs are downloaded from Maven Central, they go over HTTP, so a man in the middle proxy can replace them at will. It’s possible to sign jars, but in my experimentation with standard tools, these signatures aren’t checked. The only other verification is a SHA1 sum, which is also sent over HTTP.
  - shortstuffsushi 12y ago
    I agree that they aren't checked by default, you'd need to implement it (as the parent commenter seemed to be doing with their gradle plugin). Regarding the sums being sent over HTTP as well, seems that you'll need a checksum for your checksum. Ultimately, though, it just seems that it'd be best to avoid this while it's over HTTP.
notthetup 12y ago
This! I am totally happy donating $10 to whisper systems for this work instead of forcing me to donate $10 to Apache Foundation (although a worthy cause) to be able to get https access to Maven Central.
- moxie 12y ago
  Thanks! You can support ongoing development by sending donations to our BitHub. Anyone who commits to an Open Whisper Systems repository will get 2% of your donation: https://whispersystems.org/blog/bithub/ https://whispersystems.org/blog/bithub/ The dashboard: http://bithub.whispersystems.org/ http://bithub.whispersystems.org/
heavenlyhash 12y ago
Hi moxie, might I ask if you've considered SHA-384 instead? If I understand correctly, SHA-256 is part of the SHA-2 family of hash algorithms, and like SHA-1, when used alone it is subject to length extension attacks. SHA-384 is also a member of the SHA-2 algorithm family, but is immune to length extension attacks because it runs with an internal state size of 512 bits -- by emitting fewer bits than its total internal state, length extensions are ruled out. (Wikipedia has a great table for clarifying all these confusing names and families of hashes: [5].) Other hashes like BLAKE-2 [1], though young, also promise built-in immunity to length-extension attacks. mdm [2] is immune to this because the relevant git datastructures all include either explicit field lengths as a prefix, or are sorted lists will null terminators, both of which diffuse length extension attacks by virtue of breaking their data format if extended. Not that it's by any means easy to find a SHA-256 collision at present; but should collisions be found in the future, a length extension attack will increase the leverage for using those collisions to produce binaries that slip past this verification. An md5 Collision Demo[3] by Peter Selinger is my favourite site for concretely demonstrating what this looks like (though I think this[4] publication by CITS mentions the relationship to length extension more explicitly). (I probably don't need to lecture to you of all people about length extensions :) but it's a subject I just recently refreshed myself on, and I wanted to try to leave a decent explanation here for unfamiliar readers.) -- I'm also curious how you handled management of checksums for transitive dependencies. I recall we talked about this subject in private back in April, and one of the concerns you had with mdm was the challenge of integrating it with existing concepts of "artifacts" from the maven/gradle/etc world -- though there is an automatic importer from maven now, mdm still requires explicitly specifying every dependency. Have you found ways to insulate gradle downloading updates to plugins or components of itself? What happens when a dependency adds new transitivity dependencies? I guess that's not a threat during normal rebuilds, since specifying hashes ahead of time already essentially forbids loosely semver-ish resolution of dependencies at every rebuild, but if it does happen during an upgrade, does gradle-witness hook into gradle deeply enough that it can generate warnings for new dependencies that aren't watched? This plugin looks like a great hybrid approach that keeps what you like from gradle and while starting to layer on "pinning" integrity checks. I'll recommend it to colleagues building their software with gradle. P.S. is the license on gradle-witness such that I can fork or use the code as inspiration for writing an mdm+gradle binding plugin? I'm not sure if it makes more sense to produce a gradle plugin, or to just add transitive resolution tools to mdm so it can do first-time setup like gradle-witness does on its own, but I'm looking at it! -- Edited: to also link the wikipedia chart of hash families. -- [1] https://blake2.net/ https://blake2.net/ [2] https://github.com/polydawn/mdm/ https://github.com/polydawn/mdm/ [3] http://www.mscs.dal.ca/~selinger/md5collision/ http://www.mscs.dal.ca/~selinger/md5collision/ [4] http://web.archive.org/web/20071226014140/http://www.cits.rub.de/MD5Collisions/ http://web.archive.org/web/20071226014140/http://www.cits.ru... [5] https://en.wikipedia.org/wiki/SHA-512#Comparison_of_SHA_functions https://en.wikipedia.org/wiki/SHA-512#Comparison_of_SHA_func...
jwn 12y ago
Cool, but am I right that it requires that you trust the jar dependency you have initially on your local filesystem?

wernerb 12y ago

This is indeed a problem that needs to be addressed at some point. The MITM possibility has been mentioned before at SE http://stackoverflow.com/questions/7094035/how-secure-is-using-maven http://stackoverflow.com/questions/7094035/how-secure-is-usi...

jontro 12y ago

This is a horrible policy made by sonatype. A better alternative of mavencentral should be created...

einrealist 12y ago
It is not the fault of Sonatype. We should not trust Central right away. If I worry about malicious artifacts from Central, I must host my own repository and manage artifacts myself. And that way, I can just map other repositories I trust more.
- lmm 12y ago
  Trusting Central > Trusting everyone on the network path between you and central.

MrSourz 12y ago

I'm torn on how I feel about security being a paid feature in this case. Here the onus is being placed on the user, yet many won't be conscious of the choice they're making. The tiff mentioned in the article was interesting to read. > https://twitter.com/mveytsman/status/491298846673473536 https://twitter.com/mveytsman/status/491298846673473536

homulilly 12y ago
There's two problems with this that I see. The first is, as you said, that a lot of people won't even realize they need to pay for secure downloads. I also feel like in the case of something like a package manager, this potentially harms the wider community in ways that charging for features in a specific piece of software doesn't.
- technomancy 12y ago
  Technically paying for an auth token is not sufficient. The token cannot be used directly by Maven or Leiningen, but only by a Nexus proxying repository manager. Not a big deal if you work at a professional Clojure shop, but a huge hassle if you're freelance or just getting started.
- sitkack 12y ago
  It is like having a population partially vaccinated, almost pointless on a large scale.

femto113 12y ago

Perhaps as a stopgap Maven Central (or a concerned third party?) could publish all of the SHA1 hashes on a page that is served via HTTPS. This would at least allow tools to detect the sort of attack described in the article.

jc4p 12y ago

jCenter is the new default repository used with Android's gradle plugin, I haven't used it myself yet but it looks like the site defaults to HTTPS for everything: https://bintray.com/bintray/jcenter https://bintray.com/bintray/jcenter

sgarman 12y ago
Thanks for pointing this out, this is REALLY new, perhaps added in the most recent build. I didn't see notes for this either.
- jc4p 12y ago
  Yeah, my new projects from Android Studio Beta (released at I/O) use it as the default which was super confusing at first since I didn't see any release notes regarding it.
tdicola 12y ago
Nice, I was going to ask if maybe Google or someone invested heavily in Android could step up and provide a secure source of dependencies for everyone.
jbaruch_s 12y ago
Full disclosure - I am a developer Advocate with JFrog, the company behind Bintray. So,jcenter is a Java repository in Bintray (https://bintray.com/bintray/jcenter https://bintray.com/bintray/jcenter), which is the largest repo in the world for Java and Android OSS libraries, packages and components. All the content is served over a CDN, with a secure https connection. JCenter is the default repository in Goovy Grape (http://groovy.codehaus.org/Grape http://groovy.codehaus.org/Grape), built-in in Gradle (the jcenter() repository) and very easy to configure in every other build tool (maybe except Maven) and will become even easer very soon. Bintray has a different approach to package identification than the legacy Maven Central. We don't rely on self-issued key-pairs (which can be generated to represent anyone, actually and never verified in Maven Central). Instead, similar to GitHub, Bintray gives a strong personal identity to any contributed library. If you really need to get your package to Maven Central (for supporting legacy tools) you can do it from Bintray as well, in a click of a button or even automatically. Hope that helps!

akerl_ 12y ago

Thanks to whomever changed the title; I didn't like the original title, but couldn't come up with a better accurate one.

tensor 12y ago

The biggest problem with this policy is that new users, or even experienced ones, are likely not aware of it. This is a very serious problem that should be addressed quickly. edit: and with websites everywhere routinely providing SSL, it seem crazy that it has to be a paid feature for such a critical service.

sitkack 12y ago
Funny thing is that CERT doesn't have a problem with shenanigans like this. They are more concerned with buffer overflows than by-design stupidity.

avz 12y ago

Exposing your users to MITM attacks in order to encourage donations? Pure evil.

ternaryoperator 12y ago
That's a little paranoid. Let's see, we'll completely ruin our rep and our core business activity just so you're forced to donate--not to us, but to this open source group over here. Dude, put down the pipe.
- shawnz 12y ago
  Isn't it exactly what they are doing, though? The only reason you would want HTTPS is to prevent MITM attacks. By making it a premium feature, they are making MITM attack mitigation a premium feature.
danielweber 12y ago
If you aren't paying money, you aren't the user, you are a product. Freemium models often suck because of stuff like this[1]. But if the "users" would just consider it normal to pay money then we wouldn't have crazy things going on where people providing critical infrastructure services need to figure out how to "convert" their "users." Instead, say, every professional Java shop would pay $100 a year or so for managed access. Projects that want to use it like a CDN so their users could download would pay a fee to host it. They have bills to pay. They'll cover them one way or the other. If we pay directly at least we know what the game is. [1] They could be inserting advertising into the jars. Hey, at least it would still be a "free" service, right?
deleted 12y ago
[deleted]

clarkm 12y ago

So in principle, it's doing the same thing as: $ curl http://get.example.io | sh which we all know is bad. But in this case, it's hidden deep enough that most people don't even know it's happening.

akerl_ 12y ago
Sort-of. That has the additional non-malicious risks. A broken connection turns "rm -r /var/lib/cool/place" into "rm -r /var/" and the shell processes that.
- technomancy 12y ago
  It's also different in that the artifact signatures are there for you to check if you want to; it's just that most people don't bother, and even if you do, you probably can't tell which keys you should trust to begin with.
yonran 12y ago
Downloading from HTTP is not an issue (as far as integrity is concerned) if maven were to validate the downloads against some chain of trust. But apparently it is not. Now I am wondering what tool actually uses those .asc files that I have to generate using mvn gpg:sign-and-deploy-file when I upload new packages to sonatype...
- technomancy 12y ago
  Running `lein deps :verify` does this.
  - brl 12y ago
    How does it know what the correct signing key is? edit: Looked up answer myself. Lein downloads whatever key the signature claims to be made with from public keyservers. How does this provide any additional security over not bothering to verify signatures?

sitkack 12y ago

luarocks has the same problem. You don't need SSL, you need the packages to be signed.

technomancy 12y ago

For Leiningen at least the goal is eventually to be able to flip a switch that will make it refuse to operate in the presence of unsigned dependencies. We're still a ways away from that becoming a reality, but the default is already to refuse to deploy new libraries without an accompanying signature. Edit: of course, the question of how to determine which keys to trust is still pretty difficult, especially in the larger Java world. The community of Clojure authors is still small enough that a web of trust could still be established face-to-face at conferences that could cover a majority of authors. The situation around Central is quite regrettable though.

weavejester 12y ago
Leiningen also uses Clojars over HTTPS by default, I believe, so even without a web of trust, Clojars is still more secure than Central.
- technomancy 12y ago
  Technically true, but practically this doesn't mean anything. No one uses Clojars on its own, so if an attacker were able to perform a MITM attack, they could inject a spoofed library into the connection to Central even if the library should be fetched from Clojars.

pjlegato 12y ago

All of Maven central is only 180gb, according to https://maven.apache.org/guides/mini/guide-mirror-settings.html https://maven.apache.org/guides/mini/guide-mirror-settings.h... How hard would it be to just mirror it to S3 and use it from there via HTTPS?

technomancy 12y ago
> How hard would it be to just mirror it to S3 and use it from there via HTTPS? Trivial. Now ask: how hard would it be to pay the bandwidth charges, assuming it were a public bucket. I don't know the answer, but it's a much more interesting question.
- cordite 12y ago
  I am guessing with Amazon, even though they run Java, they wouldn't do it out of the good of their hearts.
- pjlegato 12y ago
  Yes, a very interesting question. It'd be very expensive. It occurs to me that BitTorrent technically solved the problem of high bandwidth costs long ago; millions of people transfer 1.1TB files around every day without worrying about bandwidth costs at all. Can we come up with a similar system for jars? Why are we still relying on central servers for this at all?
teraflop 12y ago
That text was last updated in 2010; currently the repository is about 1.1TB. http://search.maven.org/#stats http://search.maven.org/#stats
- pjlegato 12y ago
  Ack! This does not do anything to increase my confidence in the Maven project's guardianship of our collective security.

iancarroll 12y ago

What firewall is that? Looks nice.

MBlume 12y ago
http://www.obdev.at/products/littlesnitch/index.html http://www.obdev.at/products/littlesnitch/index.html

dandelany 12y ago

Sorry to nitpick, but you might wanna fix this typo: s/pubic/public :)

0x0 12y ago

I wonder how many enterprise apps have been backdoored through this flaw over the years by now.

sitkack 12y ago
I'd immediately backdoor the rt.jar and the compiler so that future binaries have the backdoor. Trusting trust ...

abalone 12y ago

I understand the need to raise money for projects, but the attitude[1] that security is an optional "premium" feature needs to end. It should be no different from shipping broken code. You can't just say, "oh, well we offer a premium build that actually works, for users that want that." Everybody needs it. Evernote made this mistake initially when SSL was originally a premium feature. They fixed it. Granted, there are degrees of security but protection from MITM attacks is fundamental. (Especially for executable code!) [1] https://twitter.com/mveytsman/status/491298846673473536 https://twitter.com/mveytsman/status/491298846673473536 UPDATE: @weekstweets just deleted the tweet I was referencing where he described security as a premium feature "for users who desire it" or words to that effect.

gregso 12y ago
But will users in aggregate pay more when extra effort and resources are expended on security? Will you? If the answer is no, then the smart developer has no financial incentive to do so, and every reason to segment security out as a premium feature. Maybe MITM vulnerability counts as broken code. But as always, markets win. I don't think the status quo will change until users consider security assurances worth hard dollars.
- tdicola 12y ago
  Good luck getting your users to come back and trust you after a major security incident that compromises their systems. I would turn it around and think of it this way, is it worth giving up some profit to help ensure you don't have embarrassing and damaging security issues? It's like insurance, you pay the premium and hope you never need it.
  - danielweber 12y ago
    If they aren't paying you, they aren't your users. This reinforces my priors that there is very little "free-as-in-beer" software.
    - 12y ago

GaryRowe 12y ago

I wrote a Maven plugin to avoid this. It's available under MIT licence: https://github.com/gary-rowe/BitcoinjEnforcerRules https://github.com/gary-rowe/BitcoinjEnforcerRules

passive 12y ago

For those of you in the Python world concerned about such a thing, check out Peep: https://pypi.python.org/pypi/peep https://pypi.python.org/pypi/peep It's a pip wrapper that expects you to provide hashes for your dependencies in requirements.txt. There was a lightning talk at PyCon this year, it seems super easy to use (though admittedly I'm not using it regularly yet).

jnbiche 12y ago

npm has the same problem of sending packages over http, but it's even worse since on average each node package uses about a billion other packages and because injecting malicious code in JavaScript is incredibly easy. And to be clear, just http here is not the issue. It's http combined with lack of package signing. apt runs over http, but it's a pretty secure system because of its efficient package signing. Package signing is even better than https alone since it prevents both MITM attacks and compromise of the apt repository. In fact, apt and yum were pretty ahead of their time with package signing. It's a shame others haven't followed their path.

seldo 12y ago
npm by default uses HTTPS, and has for more than 3 years. It's a little confusing because the loglines all say "http" in green, but if you actually look at the URLs being downloaded they are all to https://registry.npmjs.org/ https://registry.npmjs.org/

jgalt212 12y ago

> When can this happen? If you ever use a public wifi network in a coffee shop Just don't do this. There is no such thing as a free lunch (or wifi).

andrewchambers 12y ago
The NSA will proxy anyone they feel like.
graue 12y ago
I do it. I always thought, "What's the harm? Everything important is over SSL these days". Apparently not!

fiatmoney 12y ago

So if they need some money, what is a better revenue model for them? - charge some token amount of money to projects (harms the ecosystem, probably not a good idea) - charge some amount for projects to host old versions, or for users to access old versions (same idea as the first, just less so) - charge for access to source jars - paid javadoc hosting - rate-limiting for free users (the "file locker" model; particularly effective at convincing people sharing an office IP into paying up) Any others?

ontoillogical 12y ago
They claim the money is a donation to a open source software project, so they don't even need the money.

chetanahuja 12y ago

If I understand this correctly, maven based builds can contain dependencies on libraries hosted on remote servers. golang build system has (or had) something similar too. Witnessing this trend take hold is astonishing and horrifying in equal parts. Not just as a security problem (which is clearly obvious) but also a huge hole in software engineering practices. How can anyone run a production build where parts of your build are being downloaded from untrusted third party sources in real time? How do you ensure repeatable, reliable builds? How do you debug production issues with limited knowledge of what version of various libraries are actually running in production?

dmacvicar 12y ago
Java developers kind of laugh when I explain them that Linux distros struggle to bootstrap Maven from source due to being a non-trivial tool that depends on hundreds of artifacts to build. The point is, what do you care that your repo is local, or that your jars are secured, if the tool you got maven itself in binary form, from a server you don't control? That is the whole point of Linux distros package managers. It is not only about dependencies. Is about securing the whole chain and ensure repeatability. Maven design, unlike ant, forces you to bootstrap it from binaries. Even worse, maven itself can't handle building a project _AND_ its dependencies from source. Why will the rest of the infrastructure be important then? Yes, Linux distros build gcc and ant using a binary gcc and a binary ant. But it is always the previous build, so at some point in the chain it ends with sources and not with binaries. And this is not about Maven's idea and concept. If it had depended on a few libraries and a simple way of building itself instead of needing the binaries of half of the stuff it is supposed to build in the first place (hundreds), just to build itself.
- lmm 12y ago
  > Yes, Linux distros build gcc and ant using a binary gcc and a binary ant. But it is always the previous build, so at some point in the chain it ends with sources and not with binaries. I don't think so. The first versions of GCC were built with the C compilers from commercial UNIX from AT&T or the like. The first Linux systems were cross-built under Minix. At some point you'll go back to a program someone toggled in on the front panel, but we don't have the source for all the intermediate steps, nor any kind of chain of signatures stretching back that far. > And this is not about Maven's idea and concept. If it had depended on a few libraries and a simple way of building itself instead of needing the binaries of half of the stuff it is supposed to build in the first place (hundreds), just to build itself. Any nontrivial program should be written modularly, using existing (and, where necessary, new) libraries. Having a dependency manager to help keep track of those is a good thing. I don't see that it makes the bootstrap any more "binary"; gcc is built with a binary gcc for which source is available. Maven is built with a binary maven and a bunch of binary libraries, source for all of which is available.

deleted 12y ago

[deleted]

brianefox 12y ago

The project to offer ssl free to every user of Maven Central is already underway. Stay tuned for details.

needusername 12y ago
I'm pretty surprised that this article is news. Sonatype has been open about SSL for Maven Central since there has been Nexus or maybe even longer. I remember Jason van Zyl talking about this seven or more years ago.
ontoillogical 12y ago
Author here. Brian are you speaking as a representative of Sonatype, or are you a 3rd party?
- brianefox 12y ago
  As a representative of Sonatype. The reality of cross build injection has been discussed for many years, I even linked to an XBI talk in my blog post announcing the availability of SSL. 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 and providing multiple data centers with worldwide loadbalancing. On our first CDN provider, they could not perform SSL certificate validation and thus were themselves susceptible to a MITM attack. So the decision at that point was to run SSL off of the origin server. We wanted to make it essentially free but wanted to ensure that the bandwidth was available for those that cared to use it, hence the small donation. The situation is different today with our new CDN, they can validate the certificates all the way through and that's how we intend to deploy it. We won't be able to enable full https redirections for all traffic since this would cause havok in organizations that are firewall locked and for tools that don't follow redirects. Each tool would need to adopt the new url. I've already suggested this change occur in Maven once we launch.
  - hrjet 12y ago
    I am not familiar with Sonatype and what relation it has with maven, but have you considered adding BitTorrent protocol to maven? This might help reduce traffic considerably.

foo-licious 12y ago

It's java who cares?

jimrandomh 12y ago

My main experience with Maven has been downloading some source code, and having to use Gradle to compile it. It went and downloaded a bunch of binaries, insecurely. There were no actual unsatisfied dependencies; it was just downloading pieces of Gradle itself. I would've much rather had a Makefile. Build scripts and package managers need to be separate.

dmacvicar 12y ago
Finally someone who sees the real problem.
yourad_io 12y ago
> Build scripts and package managers need to be separate. This. Especially when there's broken links, you're gonna have a bad (and long) time.
taeric 12y ago
I will join the small chorus agreeing that build scripts and package managers should be separate. Most folks I work with disagree. Curious if anyone knows of any well done takes on this. In either way. (If I'm actually wrong, I'd like to know.) (I fully suspect there really is no "right" answer.)

joncp 12y ago

The problem goes deeper. That firewall (Little Snitch) updates itself over port 80, so most likely unencrypted.

heavenlyhash 12y ago

SSL would have partially mitigated this attack, but it's not a full solution either. SSL is transport layer security -- you still fully trust the remote server not to give you cat memes. What if this wasn't necessary? Why can't we embed the hash of the dependencies we need in our projects directly? That would give us end-to-end confidence that we've got the right stuff. This is exactly why I built mdm[1]: it's a dependency manager that's immune to cat memes getting in ur http. Anyone using a system like git submodules to track source dependencies is immune to this entire category of attack. mdm does the same thing, plus works for binary payloads. Build injection attacks have been known for a while now. There's actually a great publication by Fortify[2] where they even gave it a name: XBI, for Cross Build Injection attack. Among the high-profile targets even several years ago (the report is from 2007): Sendmail, IRSSI, and OpenSSH! It's great to see more attention to these issues, and practical implementations to double-underline both the seriousness of the threat and the ease of carrying out the attack. Related note: signatures are good too, but still actually less useful than embedding the hash of the desired content. Signing keys can be captured; revocations require infrastructure and online verification to be useful. Embedding hashes in your version control can give all the integrity guarantees needed, without any of the fuss -- you should just verify the signature at the time you first commit a link to a dependency. [1] https://github.com/polydawn/mdm/ https://github.com/polydawn/mdm/ [2] https://www.fortify.com/downloads2/public/fortify_attacking_the_build.pdf https://www.fortify.com/downloads2/public/fortify_attacking_...

michaelt 12y ago
Why can't we embed the hash of the dependencies we need in our projects directly? There's a lot of stuff in Maven, like the versions plugin and the release plugin, to update dependencies to the latest version. This stuff is useful for continuous integration and automated deployment, especially when your project is split into lots of modules to allow code reuse. With code signing, you can (or hypothetically could, I don't know if anyone does this) check the latest version is signed by the same key as the previous version - whereas just pinning the hash wouldn't allow that. I agree pinning the hash is useful if the signing key is captured.
- 12y ago

qwerta 12y ago

We store jars in git repo...

buckey 12y ago

Yeah have you ever wrote code on the play platform? There is your proof of concept at least on earlier versions static injection using annotations ... It's also how spring works and almost all dynamic ... Hell you can jit your code don't even need to compile it into a class the run time can do it for you ... That why I always compile my jar files so they can't be read as a compressed file anyway pretty cool sounds like you could have a lot of fun with someone doing this ... You could turn there computer into anything you want using Java command line functionality .... I.e. System.get(os.name) if windows do this if OS X do this if lunix do this using Java.lang.runtime.exec then after you open the back door to there computer time for socket connections and getoutputstream etc... Anyway point being java is a cross platform lang so there is a world of possibilities and most of the time they are running this from an IDE so if you inject a sudo call who knows what could happen

SanderMak 12y ago

The vulnerability even has a name: Cross-build injection attacks. I wrote about it some time ago [1], [2]. The complete answer includes verifying the (now mandatory) PGP signatures [3] of artifacts in Maven Central. But you need a web-of-trust for that and the whole process is rather impractical currently. [1] http://branchandbound.net/blog/security/2012/03/crossbuild-injection-how-safe-is-your-build/ http://branchandbound.net/blog/security/2012/03/crossbuild-i... [2] http://branchandbound.net/blog/security/2012/10/cross-build-injection-in-action?src=archive http://branchandbound.net/blog/security/2012/10/cross-build-... [3] http://branchandbound.net/blog/security/2012/08/verify-dependencies-using-pgp/ http://branchandbound.net/blog/security/2012/08/verify-depen...

tomjen3 12y ago
Instead of going WOT, why not just get a specific SHA hash, instead of a specific version?
- SanderMak 12y ago
  Sure, you could obtain a hash out-of-band and pin to that. Not much more convenient given you have to do it for all transitive dependencies and Maven-plugin dependencies as well.