Sonatype vulnerability CVE-2016-1000027 in Spring-web project

[gauravdeshmukh612]

Affects: \5.2.3.RELEASE

Issue Title : Sonartype vulnerability CVE-2016-1000027 in Spring-web project

Description
Description from CVE
Pivotal Spring Framework 4.1.4 suffers from a potential remote code execution (RCE) issue if used for Java deserialization of untrusted data. Depending on how the library is implemented within a product, this issue may or not occur, and authentication may be required.
Explanation
The org.springframework:spring-web package is vulnerable to deserialization of untrusted data leading to Remote Code Execution (RCE). The readRemoteInvocation method in HttpInvokerServiceExporter.class does not properly verify or restrict untrusted objects prior to deserializing them. An attacker can exploit this vulnerability by sending malicious requests containing crafted objects, which when deserialized, execute arbitrary code on the vulnerable system.

NOTE: This vulnerability is related to a previously reported deserialization vulnerability (CVE-2011-2894) within the package, impacting a different class.

Detection
The application is vulnerable by using this component under specific scenarios as listed out in the advisory.

Reference: https://www.tenable.com/security/research/tra-2016-20

Recommendation
There is no non-vulnerable upgrade path for this component/package. We recommend investigating alternative components or a potential mitigating control.

A warning has been provided in the official Javadocs of the HttpInvokerServiceExporter class:

"WARNING: Be aware of vulnerabilities due to unsafe Java deserialization: Manipulated input streams could lead to unwanted code execution on the server during the deserialization step. As a consequence, do not expose HTTP invoker endpoints to untrusted clients but rather just between your own services. In general, we strongly recommend any other message format (e.g. JSON) instead."

The developer's general advice also states:
"Do not use Java serialization for external endpoints, in particular not for unauthorized ones. HTTP invoker is not a well-kept secret (or an "oversight") but rather the typical case of how a Spring application would expose serialization endpoints to begin with... he has a point that we should make this case all across our documentation, including the javadoc. But I don't really see a CVE case here, just a documentation improvement.

Pivoltal will enhance their documentation for the 4.2.6 and 3.2.17 releases."

Reference: https://www.tenable.com/security/research/tra-2016-20

Root Cause
spring-web-5.2.3.RELEASE.jar <= org/springframework/remoting/httpinvoker/HttpInvokerServiceExporter.class : [2.5.1,)
Advisories
Third Party: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2016-1000027
Third Party: https://www.tenable.com/security/research/tra-2016-20
CVSS Details
CVE CVSS 3: 9.8
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

[bclozel]

This been addressed already in the documentation, as explained in the report you've copy/pasted here: see the reference documentation.

[halhelal]

If this is a matter of documentation, then this needs to be communicated with NVD. Currently, the base score is critical 9.8 and some scanners are throwing this as highly vulnerable.

https://nvd.nist.gov/vuln/detail/CVE-2016-1000027

[rstoyanchev]

@halhelal I think there is a misunderstanding.

There is no fix for this vulnerability. Java serialization is unsafe, and all we can do is advise against exposing HTTP Invoker endpoints to untrusted clients in our documentation. That we have done almost 5 years ago when this CVE was first published. However, it does not make the vulnerability go away, nor does it change its score.

Why the CVE was republished again this month, I do not know. We did not publish it in the first place so it is not ours to begin with. Having said that it can be used as a reminder to check that there are no HTTP Invoker endpoints exposed to untrusted clients. If there are none, then nothing further to do.

[sebady]

Is there a possibility to split out the HTTP invoker functionality (i.e. the package org.springframework.remoting.httpinvoker) into a separate artifact from remaining functionality in spring-web? This way clients of spring-web can sidestep (through dependency management) the portion that is considered "vulnerable" in the CVE and still use the remaining functionality of spring-web? I'm not sure how yet to re-structure spring-web to allow this.

[bclozel]

Doing this would be a breaking change and we would need to create a new artifact for that. This is typically the type of change we apply for major releases.

These classes have been part of spring-web since Spring Framework 1.1.

I guess it's hard to balance the severity of the issue and the amount of unsafe setup required to trigger it. Tools warning about such vulnerabilities don't usually have that context and they can only convey more information to users about the context of this vulnerability.

In this case, and especially since this new warning seems to be a misunderstanding, I don't think we should move this code now.

[tgit24]

I think spring team should contact NVD to know why this vulnerability all the sudden get raised to 9.8 ??

[rstoyanchev]

@tgit24 this has already been answered above.

[bclozel]

We reached out to MITRE and apparently this CVE id was allocated in 2016 but never got published as it should have been, since all other references were already public. The original CNA (CVE Numbering Authority) which allocated this id got disbanded and MITRE is merely cleaning the backlog since it took over.

Publishing this outdated CVE had the effect of triggering numerous security tools - unfortunately, there's nothing more we can do here.

TL;DR: this is an old CVE, the information is still relevant and it can't be "fixed" in Spring Framework since it's about avoiding to expose HTTP Invoker endpoints to untrusted clients - there's been an official warning about this in our documentation for years now.

[tomcruise81]

@bclozel - what about breaking it out into a separate dependency, that is by default referenced by spring-web, but would give application teams the option to exclude it at their own discretion?

Or is it so tightly intertwined with the way that spring-web works that that's not possible?

[berlinbrown]

This is still issue today, aqua scans, nexus iq scans. Veracode scans. 1000027, is there a way to get around it from the scan perspective, possibly excluding a specific jar. Sounds like spring-web can't exclude. Especially with spring boot, if you include the parent, have to include a lot of other stuff.