[SECURITY] CVE-2019-10753: Releases are built/executed/released in the context of insecure/untrusted code

[JLLeitschuh]

CWE-829: Inclusion of Functionality from Untrusted Control Sphere

The build files indicate that this project is resolving dependencies over HTTP instead of HTTPS. Any of these artifacts could have been MITM to maliciously compromise them and infect the build artifacts that were produced. Additionally, if any of these JAR files were compromised, any developers using these could continue to be infected past updating to fix this.

• spotless/_ext/eclipse-cdt/build.gradle

  Line 6 in 366c1b9

  p2Repository = "http://download.eclipse.org/tools/cdt/releases/${VER_ECLIPSE_CDT}"

• spotless/_ext/eclipse-groovy/build.gradle

  Line 6 in 96e74ec

  p2Repository = "http://dist.springsource.org/release/GRECLIPSE/e${VER_ECLIPSE}"

• spotless/_ext/eclipse-wtp/build.gradle

  Line 6 in e1734c0

  p2Repository = "http://download.eclipse.org/webtools/repository/${VER_ECLIPSE_WTP}"

This vulnerability has a CVSS v3.0 Base Score of 8.1/10
https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

This isn't just theoretical; POC code exists already to maliciously compromise jar file inflight.

See:

• https://max.computer/blog/how-to-take-over-the-computer-of-any-java-or-clojure-or-scala-developer/
• https://github.com/mveytsman/dilettante

To fix: We need to update our build.gradle so that artifacts are resolved over HTTPS instead of HTTP.

I've been finding this vulnerability in a lot of places today and have responsibly disclosed it to some of the larger organizations involved.

[nedtwigg]

I'll need to update goomph as well: https://github.com/diffplug/goomph/blob/ece1af71d3dff2458a8b353bfa37f497710f1656/src/main/java/com/diffplug/gradle/pde/EclipseRelease.java#L78

[nedtwigg]

Btw, these URLs did not support https until just a few months ago. Thanks to @JLLeitschuh and his brethren finding all the http out there in the wild :)

[nedtwigg]

And http://dist.springsource.org/ still doesn't support SSL, so we can't resolve this until/unless that domain gets an SSL cert. @fvgh do you know the emails of anyone on the greclipse team who can raise the issue of getting https working on http://dist.springsource.org/?

[JLLeitschuh]

@nedtwigg I'd reach out to Pivotal. I need to do this already for some other stuff.

When you go to http://springsource.org/ it redirects to https://spring.io/

If you have the cycles to send them an email tonight, that would be great, otherwise, I'll get to it Sunday or Monday.

[JLLeitschuh]

@nedtwigg Can you check if your artifact is available at: https://dist.springsource.com/

[nedtwigg]

It's not currently, but I found a place to raise the issue.

[nedtwigg]

I screwed up and raised a dupe. Here's the original issue: groovy/groovy-eclipse#119

[nedtwigg]

Greclipse now supports https, so we've got all the pre-reqs to resolve this. Here's our situation:

• eclipse-wtp has 3.9.5 and 3.9.6
• eclipse-cdt has 9.4.3 and 9.4.4
• eclipse-groovy has 2.9.2 and 3.0.0

My nominal plan is to publish a minor-version bugfix for each of these (so 3.9.7, 9.4.5, and 3.0.1, respectively), and then publish a new spotless which has these as the defaults. I plan to do this Sunday/Monday, so anything else that gets merged in before then can ride that train. Open to other ideas as well :)

[JLLeitschuh]

@nedtwigg I just got an email back from the pivotal team about how they added HTTPS support. Thanks for helping shake the tree.

I think it might also be good to file for a CVE number after this has all been resolved.

[nedtwigg]

Okay, the fixed jars have all been published, and we can be sure that future jars will be downloaded over https. Next up is to compare these new jars to the old jars. If they have the exact same content, then we got away with it ;-). Otherwise, we should try to figure out why they're different, and disclose our findings.

[JLLeitschuh]

@nedtwigg Any updates on the comparison task? I wish I had the resources to do this work but sadly I don't currently, I'm still uprooting this vulnerability in a bunch of other places.

[nedtwigg]

Any updates on the comparison task?

Nope. Not gonna make the top of my todo for a while. However, if someone is willing to figure out #358 - not necessarily fix it, just prove that there is or isn't a problem, then I'd be willing to stay up late to get this done.

[JLLeitschuh]

I'll see what time I get over the next week.

[JLLeitschuh]

@nedtwigg You want to compare or you just want to go the easy way out and file for the CVE? I'm happy to file.

[nedtwigg]

I build a differ for a living! I want to compare!! It's not the top of my real work pile, but it is the top of my fun stuff pile. If this is holding up your real work pile, I'll try to move it up.

[JLLeitschuh]

I build a differ for a living! I want to compare!!

Bahahhaha. Of course. Why hadn't I thought of that?

My public (as in more public than this) disclosure date is June 10th, 2019.
If you can do this by June 1st, that would really help.

If you build something to automate this process, I can guarantee that it would have applicability outside spotless.

[jbduncan]

@JLLeitschuh, I believe that @nedtwigg would not need to automate much if at all, because there already exists a differ named diffoscope which IIRC can be used to compare two jars.

[JLLeitschuh]

That's a good find. Thanks! I should send that off to some of the other organizations I'm in contact with.

[nedtwigg]

I believe that @nedtwigg would not need ... much if at all, because there already exists a differ ...

Telling a programmer there's already a library to do X is like telling a songwriter there's already a song about love

[JLLeitschuh]

@nedtwigg Friendly heads up about a 20-day deadline. Ideally, if you could have this resolved by June 1st, that would be ideal.

[nedtwigg]

Finally taking a swing at this...

[nedtwigg]

We have 3 libraries in question: wtp, cdt, and groovy. For each library, there were 2 versions that had been published in the context of http-downloaded artifacts, and the later of the two versions was re-released exactly as-is having been built with https. This means that the later of the two versions is easy to verify, but the earlier versions are harder.

I was able to verify that WTP 3.9.6 == 3.9.7, and CDT 9.4.4 == 9.4.5, so those are definitely green. It's hard to verify the earlier versions, WTP 3.9.5 and CDT 9.4.3 because there's no HTTPS-built artifact to compare them to, and reproducing them with HTTPS now is tricky, for a reason I get to later:

For groovy, we would expect 3.0.0 == 3.0.1, but it does not. However, groovy was the library where the upstream had to make significant changes to make HTTPS available at alll.

For all of these artifacts, they have two kinds of content:

• a little bit of shim code that we write
• a lot of eclipse code which isn't available in maven repositories (only via p2), which we shade in

The problem is that p2 is not super-duper repeatable. The way that p2 resolves artifacts is designed to "update to latest", and repeatability is a secondary concern. That is a mistake, and part of the whole point of us repackaging these artifacts onto maven is to fix that mistake.

I spent some (too much!) time digging through class files, and I see no cause for concern. But, I can only definitively vouch for WTP 3.9.6 and CDT 9.4.4. I cannot definitively vouch for WTP 3.9.5, CDT 9.4.3, Groovy 3.0.0, nor Groovy 2.9.2.

[JLLeitschuh]

@nedtwigg I should have said something about this. Certain versions of Groovy injected date stamps into the bytecode thus making diffing a PITA.

Can you do me the favor of throwing together a markdown table with the following headers?

Name	Artifact ID	First Known Good Version	First known Good Spotless Version

Something like this can help: https://www.tablesgenerator.com/markdown_tables#

[nedtwigg]

Artifact ID	First Known Good Version	First known Good Spotless Version
spotless-eclipse-wtp	3.9.6	x.19.0
spotless-eclipse-cdt	9.4.4	x.19.0
spotless-eclipse-groovy	3.0.1	x.19.0

[JLLeitschuh]

The blog post is finally public! Share it on Twitter!

Want to take over the Java ecosystem? All you need is a MITM!

[jbduncan]

Awesome blog post, @JLLeitschuh! I've just shared it internally at my company. :)

It's unclear to me what we should do now to get this issue closed. 🤔 @JLLeitschuh Thoughts?

[JLLeitschuh]

I'm waiting for Snyk to issue the CVE number for this. I'll close this when we have that.

[nedtwigg]

Do we have a CVE?

[JLLeitschuh]

Been busy, I was at DEFCON last week and so was totally off the grid, sorry for not getting back to you sooner.

I'm having a chat with Danny at Snyk on the 20th to get this ironed out.

[nedtwigg]

While I've got security on the mind, any news on this front?

[JLLeitschuh]

Still waiting for an answer from @grnd at Snyk to get back to me.

@grnd any updates?

[leeyashalti]

@JLLeitschuh @nedtwigg Hi I'm Leeya, Security Analyst at Snyk.
We issued a CVE number - CVE-2019-10753. It will be public soon but meanwhile, we added the issue to our db:
SNYK-JAVA-COMDIFFPLUGGRADLESPOTLESS-174875
SNYK-JAVA-COMDIFFPLUGGRADLESPOTLESS-174876
SNYK-JAVA-COMDIFFPLUGSPOTLESS-460377
I believe you can close the issue now 🙂

[JLLeitschuh]

Thank you @leeyashalti!

[leeyashalti]

https://nvd.nist.gov/vuln/detail/CVE-2019-10753

[JLLeitschuh]

@leeyashalti Can you add an informational link to this issue on the CVE?

[nedtwigg]

Thanks for all the work on this @JLLeitschuh and @leeyashalti.