[SECURITY] Use HTTPS to resolve dependencies in Maven Build

[JLLeitschuh]

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

---

This is a security fix for a vulnerability in your Apache Maven pom.xml file(s).

The build files indicate that this project is resolving dependencies over HTTP instead of HTTPS.
This leaves your build vulnerable to allowing a Man in the Middle (MITM) attackers to execute arbitrary code on your or your computer or CI/CD system.

This vulnerability has a CVSS v3.0 Base Score of 8.1/10.

POC code has existed since 2014 to maliciously compromise a JAR file in-flight.
MITM attacks against HTTP are increasingly common, for example Comcast is known to have done it to their own users.

This contribution is a part of a submission to the GitHub Security Lab Bug Bounty program.

Detecting this and Future Vulnerabilities

This vulnerability was automatically detected by LGTM.com using this CodeQL Query.

As of September 2019 LGTM.com and Semmle are officially a part of GitHub.

You can automatically detect future vulnerabilities like this by enabling the free (for open-source) LGTM App.

I'm not an employee of GitHub nor of Semmle, I'm simply a user of LGTM.com and an open-source security researcher.

Source

Yes, this contribution was automatically generated, however, the code to generate this PR was lovingly hand crafted to bring this security fix to your repository.

The source code that generated and submitted this PR can be found here:
JLLeitschuh/bulk-security-pr-generator

Opting-Out

If you'd like to opt-out of future automated security vulnerability fixes like this, please consider adding a file called
.github/GH-ROBOTS.txt to your repository with the line:

User-agent: JLLeitschuh/bulk-security-pr-generator
Disallow: *

This bot will respect the ROBOTS.txt format for future contributions.

Alternatively, if this project is no longer actively maintained, consider archiving the repository.

CLA Requirements

This section is only relevant if your project requires contributors to sign a Contributor License Agreement (CLA) for external contributions.

It is unlikely that I'll be able to directly sign CLAs. However, all contributed commits are already automatically signed-off.

The meaning of a signoff depends on the project, but it typically certifies that committer has the rights to submit this work under the same license and agrees to a Developer Certificate of Origin
(see https://developercertificate.org/ for more information).

- Git Commit Signoff documentation

If signing your organization's CLA is a strict-requirement for merging this contribution, please feel free to close this PR.

Tracking

All PR's generated as part of this fix are tracked here:
JLLeitschuh/bulk-security-pr-generator#2

[senivam]

copyright year here:
Copyright (c) 2012, 2019 Oracle and/or its affiliates. All rights reserved.
shall be updated as soon as the line was changed.

[JLLeitschuh]

Go for it. Allow edits from maintainers is checked.

[JLLeitschuh]

CC: @waynebeaton

[waynebeaton]

CC: @waynebeaton

Is this just an FYI, or do you need something specific from me (sorry to be daft, but I'm not able to grok it from the thread).

[JLLeitschuh]

Does this need a CVE number assigned to it. Similar to previous vulns reported against eclipse projects?

[waynebeaton]

Does this need a CVE number assigned to it. Similar to previous vulns reported against eclipse projects?

Whether or not a CVE is required is entirely a project's decision. If you're not sure and would like some assistance, connect with your PMC (ee4j-pmc@eclipse.org) or the Security team (security@eclipse.org).

Having said that, if you believe that there are release builds of Eclipse Jersey (specifically release builds that have been created since the project moved to the Eclipse Foundation) in the wild (i.e., in use by adopters) that are compromised, then we're really honour bound to create a CVE. If you've just patched your build because of a potential exploit with no evidence to suggest that the exploit has leveraged its way into your release builds, my inclination is that no CVE is required. I, of course, defer to the project team's wisdom.

Is that enough to go on?

If you do decide to request a CVE, the process is described in the handbook.

[JLLeitschuh]

More or less. I just want to make you aware that I opened one of these against a bunch of eclipse projects. I wrote a bot to automate fixing this vulnerability across every project that LGTM had indexed. Ended up creating 1,596 PRs in total.

Here are all the PRs for all the projects I patched that are part of the eclipse foundation:

• [SECURITY] Use HTTPS to resolve dependencies in Maven Build jakartaee/security-examples#9
• [SECURITY] Use HTTPS to resolve dependencies in Maven Build eclipsesource/jshint-eclipse#125
• https://github.com/eclipse/linuxtools/pull/22
• [SECURITY] Use HTTPS to resolve dependencies in Maven Build eclipse/reddeer#2061
• [SECURITY] Use HTTPS to resolve dependencies in Maven Build eclipselink-examples#1
• [SECURITY] Use HTTPS to resolve dependencies in Maven Build eclipse-collections/eclipse-collections#796
• Use HTTPS to resolve ruby gems for Jekyll website build eclipse-ditto/ditto#617
• [SECURITY] Use HTTPS to resolve dependencies in Maven Build eclipse-pdt/pdt#43
• https://github.com/eclipse/mylyn.docs/pull/13
• [SECURITY] Use HTTPS to resolve dependencies in Maven Build deeplearning4j/deeplearning4j-examples#941