-
Notifications
You must be signed in to change notification settings - Fork 455
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SECURITY] CVE-2019-10753: Releases are built/executed/released in the context of insecure/untrusted code #360
Comments
I'll need to update |
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 :) |
And |
@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. |
@nedtwigg Can you check if your artifact is available at: https://dist.springsource.com/ |
It's not currently, but I found a place to raise the issue. |
I screwed up and raised a dupe. Here's the original issue: groovy/groovy-eclipse#119 |
Greclipse now supports https, so we've got all the pre-reqs to resolve this. Here's our situation:
My nominal plan is to publish a minor-version bugfix for each of these (so |
@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. |
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. |
@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. |
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. |
I'll see what time I get over the next week. |
@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. |
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. |
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 build something to automate this process, I can guarantee that it would have applicability outside spotless. |
@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. |
That's a good find. Thanks! I should send that off to some of the other organizations I'm in contact with. |
|
@nedtwigg Friendly heads up about a 20-day deadline. Ideally, if you could have this resolved by June 1st, that would be ideal. |
Finally taking a swing at this... |
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:
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. |
@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?
Something like this can help: https://www.tablesgenerator.com/markdown_tables# |
|
The blog post is finally public! Share it on Twitter! Want to take over the Java ecosystem? All you need is a MITM! |
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? |
I'm waiting for Snyk to issue the CVE number for this. I'll close this when we have that. |
Do we have a CVE? |
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. |
While I've got security on the mind, any news on this front? |
@JLLeitschuh @nedtwigg Hi I'm Leeya, Security Analyst at Snyk. |
Thank you @leeyashalti! |
@leeyashalti Can you add an informational link to this issue on the CVE? |
Thanks for all the work on this @JLLeitschuh and @leeyashalti. |
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
spotless/_ext/eclipse-groovy/build.gradle
Line 6 in 96e74ec
spotless/_ext/eclipse-wtp/build.gradle
Line 6 in e1734c0
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:
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.
The text was updated successfully, but these errors were encountered: