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.

[bclozel]

This will be addressed in #25379

[cvmocanu]

First, I want to thank the Spring Framework team for doing a great work - we are many developers depending on you guys.

@bclozel : that ticket just deprecate the class, and it will be removed in Spring 6.

This is a big problem because:

• the NexusIQ in the company I work for tags spring-web as unacceptable because of CVE-2016-1000027. I'm sure others face similar issues.
• it's very doubtful that we will be allowed to change the NexusIQ rules, since this is a real critical vulnerability

Given the above, the solutions I see are:

• hack the build process to delete that class from the jar; in addition to being a huge hack, I'm not even sure if it would work (since the scanner may just look at the maven GAV coordinates, not at the classes inside the jar).
• give up spring-web; Webflux would be an alternative, but it comes with too many disadvantages (e.g. uninformative thread dumps, complicated java code, etc.) and it gives no advantage back if you don't have a fully reactive stack (all the way to the database). In addition, if you don't need the performance, you pay the costs without getting the advantages. Since there is no good blocking alternative to spring-web, this means giving up spring web for some other web framework. Since spring-boot needs either spring-web or webflux, this also means giving up spring-boot. And if we give up that, we might as well give up spring entirely.

As you can see, this is a huge issue, and we need a solution way before Spring 6 will be released (I couldn't find an estimated release date).

Producing a separate artifact (spring-web-clean?) that doesn't contain any class doing java serialization should fix the issue.

@tomcruise81's suggestion above might not work if the scanner just looks at the GAV coordinates.

[bclozel]

Hi @cvmocanu

Thanks for reaching out - and thanks for being part of the community! I'm sorry about the situation you're facing; I've been chatting on gitter/mail with people about this particular situation. Many developers are having the same issue in their organization.

For the sake of this thread, I'll quickly summarize the situation again:

A variant of CVE-2011-2894 was submitted in 2016 by security researchers to a now disbanded CNA (CVE Numbering Authority). Years later, in 2020, this CVE was published by another CNA as a way to process all outstanding reports.

This issue is another variant of "Java deserialization from untrusted sources". Doing so is exposing your application to remote code execution. This vulnerability is present at the JDK level as well, no Spring involved. This is why we've documented over the years, that developers should pay attention to that point. In this case, as opposed to 2011, the highest critical score is triggering all kind of automated rules...

Given the current trends and the security challenges, we've decided to remove this particular support in #25379.

We know that deprecating that class does not solve the problem at hand for development teams. Given that CVE report, we're not even sure that those automated rules will stop applying to those tools in the future when the class will be deleted - in fact, this CVE report is tagged for Spring Framework 4.1.4 but it still applies to 5.x, so I guess vendors are adding metadata in their systems?

Back to your situation @cvmocanu. The main problem here is that this security process comes without any context: from the critical score of the initial CVE to the rules enforced in your NexusIQ instance, most of it is done automatically. If companies around the world would be strictly enforcing this rule without context, there would be no Spring MVC nor any kind of Java application accepting traffic deployed in production since 2011: they're all "vulnerable".

I guess that tools like NexusIQ aren't doing static code analysis but rather just looking at the dependency graph - otherwise they wouldn't flag your application: looking for HTTPInvokerServiceExporter or RemoteInvocationSerializingExporter usage in the application code would be an easy way to prevent most false positives.

We don't think the solutions you're thinking about will solve the problem:

• As said above, security tools are probably looking at the dependency graph only. Removing the class is not likely to solve the problem. Shading the library might work, but you're really working around security rules and likely to miss genuine CVE alerts in the future.

• When it comes to modules, Spring MVC is spring-webmvc and Spring WebFlux is spring-webflux. spring-web is the shared infrastructure for both Web Frameworks. A WebFlux app still depends on spring-web.

I'd suggest sharing your experience with your security team and security vendor: if developers need to consider switching development stack completely because tools and processes raise false positives (again, if your application does not deserialize Java from untrusted sources, your app is safe in that regard!), there's a broader problem that needs to be addressed.

Producing new artifacts every time a problem like that happens is not sustainable technically and as a community. It feels like we're trying to solve organizational issues from a pure technical perspective, and this rarely works. I'd be happy to chat with your security team/vendor about this particular problem. Feel free to reach out to me (my contact info is on my github profile).

[Mert-Z]

First, I want to thank the Spring Framework team for doing a great work - we are many developers depending on you guys.

@bclozel : that ticket just deprecate the class, and it will be removed in Spring 6.

This is a big problem because:

• the NexusIQ in the company I work for tags spring-web as unacceptable because of CVE-2016-1000027. I'm sure others face similar issues.
• it's very doubtful that we will be allowed to change the NexusIQ rules, since this is a real critical vulnerability

Given the above, the solutions I see are:

• hack the build process to delete that class from the jar; in addition to being a huge hack, I'm not even sure if it would work (since the scanner may just look at the maven GAV coordinates, not at the classes inside the jar).
• give up spring-web; Webflux would be an alternative, but it comes with too many disadvantages (e.g. uninformative thread dumps, complicated java code, etc.) and it gives no advantage back if you don't have a fully reactive stack (all the way to the database). In addition, if you don't need the performance, you pay the costs without getting the advantages. Since there is no good blocking alternative to spring-web, this means giving up spring web for some other web framework. Since spring-boot needs either spring-web or webflux, this also means giving up spring-boot. And if we give up that, we might as well give up spring entirely.

As you can see, this is a huge issue, and we need a solution way before Spring 6 will be released (I couldn't find an estimated release date).

Producing a separate artifact (spring-web-clean?) that doesn't contain any class doing java serialization should fix the issue.

@tomcruise81's suggestion above might not work if the scanner just looks at the GAV coordinates.

just as a note, Webflux also pulls in spring-web as a dependency;

[INFO] |  +- org.springframework.boot:spring-boot-starter-webflux:jar:2.4.2:compile
[INFO] |  |  +- org.springframework.boot:spring-boot-starter-json:jar:2.4.2:compile
[INFO] |  |  +- org.springframework.boot:spring-boot-starter-reactor-netty:jar:2.4.2:compile
[INFO] |  |  |  \- io.projectreactor.netty:reactor-netty-http:jar:1.0.3:compile
[INFO] |  |  |     +- io.netty:netty-codec-http:jar:4.1.58.Final:compile
[INFO] |  |  |     |  +- io.netty:netty-common:jar:4.1.58.Final:compile
[INFO] |  |  |     |  +- io.netty:netty-buffer:jar:4.1.58.Final:compile
[INFO] |  |  |     |  +- io.netty:netty-transport:jar:4.1.58.Final:compile
[INFO] |  |  |     |  +- io.netty:netty-codec:jar:4.1.58.Final:compile
[INFO] |  |  |     |  \- io.netty:netty-handler:jar:4.1.58.Final:compile
[INFO] |  |  |     +- io.netty:netty-codec-http2:jar:4.1.58.Final:compile
[INFO] |  |  |     +- io.netty:netty-resolver-dns:jar:4.1.58.Final:compile
[INFO] |  |  |     |  +- io.netty:netty-resolver:jar:4.1.58.Final:compile
[INFO] |  |  |     |  \- io.netty:netty-codec-dns:jar:4.1.58.Final:compile
[INFO] |  |  |     +- io.netty:netty-resolver-dns-native-macos:jar:osx-x86_64:4.1.58.Final:compile
[INFO] |  |  |     |  \- io.netty:netty-transport-native-unix-common:jar:4.1.58.Final:compile
[INFO] |  |  |     +- io.netty:netty-transport-native-epoll:jar:linux-x86_64:4.1.58.Final:compile
[INFO] |  |  |     \- io.projectreactor.netty:reactor-netty-core:jar:1.0.3:compile
[INFO] |  |  |        \- io.netty:netty-handler-proxy:jar:4.1.58.Final:compile
[INFO] |  |  |           \- io.netty:netty-codec-socks:jar:4.1.58.Final:compile
[INFO] |  |  +- org.springframework:spring-web:jar:5.3.3:compile

[tomcruise81]

To add context, I believe the the GAV coordinates are sufficient:

Here's Nexus IQ's analysis of an older version of spring-web:

And here's it's analysis of an older version of spring-expression, which suffered from CVE-2018-1270:

Note that for spring-expression, possible remediation is to upgrade to 4.3.17:

Select 4.3.17.RELEASE: Next version with no policy violation

So it does appear that GAV coordinates should be sufficient.

[bclozel]

I'm not sure that helps unfortunately @tomcruise81

In the case of CVE-2018-1270, the CVE metadata itself contains a "patched version" information pointing to 4.3.16.RELEASE (as mentioned in the official CVE report). Is there a particular reason 4.3.17.RELEASE is selected here instead?

In our case here, there is no "patched version" information attached to the CVE report. It looks like we're dealing here with a 4.1.4-* version range. By the time the offending classes are removed from the JAR, the version range will still be there. We'll have to get in touch with MITRE and vendors to update this information - technically the current information is already not 100% accurate.

[artem-smotrakov]

FYI

Vulnerable applications can be detected using static code analysis.

If you use CodeQL, I've created two CodeQL queries that detect vulnerable service exporters:

• Detecting unsafe service exporters in configuration classes
• Detecting unsafe service exporters in XML configs

This blog post describes the issue, shows an example of vulnerable code, and describes the queries.

[cvmocanu]

It's very disappointing to see the Spring team refusing to split the vulnerable class into a separate module. This would indeed be a braking change (people who actually use that class would have to manually bring-in a new dependency), but I think it would affect very few people.

Pushing for better tools (like CodeQL, if it's indeed better) is a fair point, and I'm going to try to at least get it considered, but it may take many months (or even years) in a large organization to change tools. In the mean time, we have to feel the pain. And while the source of the pain is the processes of the organization, it wouldn't be too difficult for the Spring team to fix this issue.

Another thing to ponder: why is it that, from 276 libraries, spring-web is the only one that causes issues?

[OrangeDog]

NVD have just updated this vulnerability ( Reanalysis 5/19/2022 10:25:56 AM ) so it now applies to all versions up to (excluding) 6.0.0.

Was there a fix in 5.3.17 / 5.4.0 (as it previously said), or has this vulnerability actually still been there the whole time?

Is there any communication as to why they changed it?

[bclozel]

Thanks for the update @OrangeDog

NVD have just updated this vulnerability ( Reanalysis 5/19/2022 10:25:56 AM ) so it now applies to all versions up to (excluding) 6.0.0.

Indeed, the CVE has been recently updated.

Was there a fix in 5.3.17 / 5.4.0 (as it previously said), or has this vulnerability actually still been there the whole time? Is there any communication as to why they changed it?

There never was a vulnerability per se. Developers could use remoting support in spring-web to perform Java deserialization from untrusted clients, if exposed publicly. This can happen without Spring being involved and is a well-known Java security problem. This has been explained in a previous comment here.

No fix was applied, since there was nothing to fix in the first place; we've updated the reference documentation 10+ years ago. We've deprecated this technology in #25379 and removed it completely in #27422.

We didn't get any communication about this. I guess someone noticed that these classes were removed from Spring Framework in #27422, won't be part of the 6.0 release and managed to get this updated. It's good news, tools will finally stop highlighting this CVE, which is a false positive from my perspective.

[jpcmonster]

In the short term it may cause more noise though; OWASP DependencyCheck began sounding the alarm in our CI a few hours ago.

[bclozel]

@jpcmonster if this tool didn't flag this previously, you should report this as an issue to the project your vendor. A simple update on the range (with the same outcome) should not change anything for projects.

[mtarnawa]

@bclozel are you planning to liaise with NVD on this at any point? This is a bit of a disaster: tools that rely on NVD as the source of vulnerabilities are now flagging almost all versions of SF in existence with a 9.8 CVSS score. This is almost log4shell-critical while being... nonsense.

[dmitry-weirdo]

Tonight. all the pipelines suddenly started to fail with GitLab dependency check:

[ERROR] Failed to execute goal org.owasp:dependency-check-maven:7.1.0:check (default-cli) on project ins-app: 
[ERROR] 
[ERROR] One or more dependencies were identified with vulnerabilities that have a CVSS score greater than or equal to '8.0': 
[ERROR] 
[ERROR] spring-core-5.3.20.jar: CVE-2016-1000027(9.8)
[ERROR] spring-tx-5.3.20.jar: CVE-2016-1000027(9.8)
[ERROR] 
[ERROR] See the dependency-check report for more details.

Please fix or communicate this with NVD!

[enote-kane]

For anyone using the dependency-check (e.g. @dmitry-weirdo ), after verifying that you're not affected, add a suppression:

<?xml version="1.0" encoding="UTF-8"?>
<!--
Documentation: https://jeremylong.github.io/DependencyCheck/general/suppression.html
-->
<suppressions xmlns="https://jeremylong.github.io/DependencyCheck/dependency-suppression.1.3.xsd">
    <suppress>
        <notes><![CDATA[Ignored since we are not vulnerable]]></notes>
        <packageUrl regex="true">^pkg:maven/org\.springframework/spring.*$</packageUrl>
        <cve>CVE-2016-1000027</cve>
    </suppress>
</suppressions>

People really need to stop freaking out, calm down, read the issue and do their responsibility.

[act-amirsky]

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.

The problem is that major organization's security groups can have a zero-tolerance policy for High/Critical issues in a security scan. Our software goes to major banks, and we've tried, explained, begged for exceptions around a flagged library that is not really exposing a CVE in any context - but to no avail. I understand their perspective on this. They have to maintain the security of 1000s of applications and services running in massive organizations. They don't have the energy nor endless expertise to debate each flagged library and weight the risk of a data breach in the bank.

I am all for removing to a separate lib - with all understanding on the "breaking" impact. Though I think with such a blaringly clear reason and that the fix is an added dep to a POM, it benefits may out-weight the update costs IMHO.

Is there no way to add mitigations or validations in the HttpInvoker around this? Enough in order to negate this CVE? If backwards compatibility is a concern make the mitigations/validation an enabled capability which is off by default.

[cvmocanu]

begged for exceptions around a flagged library that is not really exposing a CVE in any context - but to no avail

I'm a senior software developer, but if I were a security officer, I wouldn't give an exception in this case. Especially with spring boot autoconfiguration, just including the wrong jar in the list of dependencies (deep in the dependency tree) can expose an endpoint that makes the application vulnerable - and it has almost 0% chance to be catched by a PR review.

The only safe course is to not have the option - for the vulnerable class not to be available on the classpath. But Spring developers don't see (or refuse to see) this.

(Off-topic: I can't wait for Spring Fu, where all the magic is made explicit).

[bclozel]

@mtarnawa @dmitry-weirdo I've reached out to MITRE a few days ago as it is the team that initially published it. I'm still waiting for an answer.

@act-amirsky at this point the best course of action is to get this CVE entry removed as invalid. Splitting, changing the existing support might just trigger more updates to the entry and more alarm bells, so not fix the root issue. I totally understand the security processes of big companies; for these to work, we need reliable, accurate CVE information. This is not the case here and this should be fixed.

@cvmocanu there is no auto-configuration for this in Spring Boot. Developers need to expose this manually in all cases. This is why the CVSS score is wrong in the first place. Spring Fu would be "vulnerable" in a similar fashion. Not having the related classes on the classpath won't solve the issue: it is really easy to replicate the same behavior by using regular REST endpoints and vanilla Java serialization. The security issue isn't in Spring's code, but rather a general Java security concern: do not deserialize Java classes from untrusted clients.

[cvmocanu]

@bclozel : you misunderstood my comment. My point was that the presence of the class in the classpath makes a particular attack much simple:

• the spring boot autoconfiguration works automatically, by just adding an artifact to the classpath
• a malicious 3rd party artifact (one of the tens of such artifacts) could auto-configure the vulnerable controller
• the fact that a 3rd party artifact is added to the classpath is completely not obvious to any PR review, because it could be a transitive dependency of a transitive dependency

All the above makes it very easy to introduce a security issue into an application in a way that is completely impossible to see in a PR review.

Of course, the problem is not specific to this issue, but it's generic to spring boot autoconfiguration - it's very easy to introduce a security issue into an application, in a way that passes the PR review. Servlet 3.0 auto-scanning has the same problem, for the same reasons. That's why I said that I can't wait until Spring Fu becomes production ready. In addition to removing the possibility to introduce such security issues invisibly, it will also require people to understand how Spring works. This will remove the endless debugging sessions into Spring code trying to understand what autoconfiguration classes need to be included in a test (since there is very little official documentation about this).

The security issue isn't in Spring's code, but rather a general Java security concern: do not deserialize Java classes from untrusted clients.

I agree that Java serialization is the root cause. It will probably (hopefully) be removed from Java completely in the next years. But the presence of HttpInvokerServiceExporter in the classpath, coupled with Spring Boot autoconfiguration makes some attacks much easier than they should be.

[bclozel]

@cvmocanu

All the above makes it very easy to introduce a security issue into an application in a way that is completely impossible to see in a PR review.

Again, Spring Boot does not auto-configure nor expose HttpInvokerServiceExporter, in any way. Also, there is no controller involved, as the HttpInvokerServiceExporter needs to be declared manually as a bean and exposed through a Servlet. The scenario you've described can easily be applied without Spring being involved. As you've pointed out, Servlet 3 scanning, a servlet implementation and plain Java deserialization can achieve the same.

Of course, the problem is not specific to this issue, but it's generic to spring boot autoconfiguration

I understand that you have a preference for manual configuration. Lots of developers are following this issue and are looking for guidance about the CVE; making your point about auto-configuration here just adds to the confusion.

But the presence of HttpInvokerServiceExporter in the classpath, coupled with Spring Boot autoconfiguration makes some attacks much easier than they should be.

Please stop making this point as we've shown this is not true. Also, I'm asking you to refrain from commenting further on this issue, your opinion has been heard. If you believe you've found critical information about this vulnerability, please report it responsibly. We don't want to lock this conversation but we will if this becomes too noisy.

[joubin]

@mtarnawa @dmitry-weirdo I've reached out to MITRE a few days ago as it is the team that initially published it. I'm still waiting for an answer.

Did you ever hear back from MITRE?

[act-amirsky]

Thank you, krshreyassu This is indeed great news!

From: krshreyassu @.> Sent: Thursday, July 14, 2022 4:08 PM To: spring-projects/spring-framework @.> Cc: Aaron Mirsky @.>; Mention @.> Subject: Re: [spring-projects/spring-framework] Sonatype vulnerability CVE-2016-1000027 in Spring-web project (#24434)

EXTERNAL EMAIL

This vulnerability is fixed in the latest version - org.springframework : spring-web : 5.3.22

— Reply to this email directly, view it on GitHubhttps://github.com/spring-projects/spring-framework/issues/24434#issuecomment-1184427527, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AV73Y4E347M7WE5GRFVCCFDVUAGMRANCNFSM4KL4M22Q. You are receiving this because you were mentioned.Message ID: @.**@.>>

Confidentiality: This communication and any attachments are intended for the above-named persons only and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of NICE Actimize. If this communication has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender by e-mail immediately. Monitoring: NICE Actimize may monitor incoming and outgoing e-mails. Viruses: Although we have taken steps toward ensuring that this e-mail and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free.

[bclozel]

@joubin The latest updates we received on the matter suggest that the process is still ongoing on their side, see this twitter thread and this GitHub PR.

You can reach out to the MITRE team using the CVE form if you want to send feedback about this CVE.

[dmitry-weirdo]

This CVE started to fail again with org.owasp:dependency-check-maven updated to v7.1.2. Is it still to be ignored?

[bclozel]

@dmitry-weirdo The suppression in dependency-check is still here as far as I know, if there's a problem you should report it to the DependencyCheck project directly.

[ecroys]

@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.

Yesterday Blackduck started to complain about this CVE again. Wouldn't be possible to isolate the "dangerous" feature in another artifact and void the common SpringWeb applications to explain it's not using it?

[bclozel]

@ecroys this has been adresses in this comment already: https://github.com/spring-projects/spring-framework/issues/24434#issuecomment-744519525

[ecroys]

@ecroys this has been adresses in this comment already: #24434 (comment)

Thanks for you answer @bclozel. My point of view, this change is not to solve organizational issues, but to isolate a feature which is potential dangerous when misused. I completely understand that it depends on the developer to do not expose it. Considering the level of the risk, the framework could help on unnecessary exposure, isolating it in an artifact which only the devs knowing what they are doing and requiring it would use.

[bclozel]

@ecroys we've marked the related classes as deprecated in 5.3.0, which should already send a visible signal to developers and they're removed as of 6.0. Moving those to a different artifact is really about failing to work around this CVE - not only this would create more problems as we'd be introducing split packages in our dependency arrangement, it also wouldn't help at all if the dependency itself is brought transitively in your build.

This very ticket shows that this is very much a security process + organizational issue. We're getting the same amount of feedback (and long lasting) than serious security concerns. Java deserialization and ways to secure it has never been the subject of the conversation with orgs affected, as they're not using this feature - it's always been about making this CVE go away.

We're still discussing this case with MITRE; we'll share the results here as soon as we can.

[act-amirsky]

Hi Brian,

I tried to hold make my suspense as much as possible 😊 Any answers from Mitre? Side idea: If the concern if breaking changes from removing the deprecated classes – what about a 5.4.0 release making the version change impact more declared?

Thanks for keeping us in the loop. Love Spring!

Aaron

[bclozel]

Hi Aaron,

Discussions are still ongoing with MITRE. We'll share the result here as soon as we can. There won't be any 5.4.0 version - 6.0.0 is removing those already, a major version is the right call here for this type of change. Thanks!

[act-amirsky]

Hi,

Trying to give some wait time in order not to spam. I see your 5.3.22 release is out. Have you heard back from MITRE?

From: Brian Clozel @.> Sent: Monday, July 18, 2022 10:25 AM To: spring-projects/spring-framework @.> Cc: Aaron Mirsky @.>; Mention @.> Subject: Re: [spring-projects/spring-framework] Sonatype vulnerability CVE-2016-1000027 in Spring-web project (#24434)

EXTERNAL EMAIL

@joubinhttps://github.com/joubin The latest updates we received on the matter suggest that the process is still ongoing on their side, see this twitter threadhttps://twitter.com/CVEannounce/status/1534284114290954245 and this GitHub PRhttps://github.com/CVEProject/cvelist/pull/5949#issuecomment-1153931058.

You can reach out to the MITRE team using the CVE formhttps://cveform.mitre.org/ if you want to send feedback about this CVE.

— Reply to this email directly, view it on GitHubhttps://github.com/spring-projects/spring-framework/issues/24434#issuecomment-1186855015, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AV73Y4EZUD3PMI7CNIW3MC3VUUBFRANCNFSM4KL4M22Q. You are receiving this because you were mentioned.Message ID: @.**@.>>

Confidentiality: This communication and any attachments are intended for the above-named persons only and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of NICE Actimize. If this communication has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender by e-mail immediately. Monitoring: NICE Actimize may monitor incoming and outgoing e-mails. Viruses: Although we have taken steps toward ensuring that this e-mail and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free.

[varshith-v]

Hi @bclozel, As I see from comments, the classes concerned with this CVE are HTTPInvokerServiceExporter, RemoteInvocationSerializingExporter and are deprecated. Could you please confirm if there are any other classes concerned with this vulnerability?

[bclozel]

@varshith-v the CVE is really about Java deserialization, so ObjectInputStream is really the one to look for in your code base. In Spring Framework, the classes you listed are the ones that leverage this mechanism.

[act-amirsky]

Hi Aaron,

Discussions are still ongoing with MITRE. We'll share the result here as soon as we can. There won't be any 5.4.0 version - 6.0.0 is removing those already, a major version is the right call here for this type of change. Thanks!

Hi again Brian (@bclozel )

I understand the rational but implore you to reconsider some 5.4 or 5.3.24 version that can mitigate this. This is because - to my understanding - Spring 6 has some pretty major environment changes such as a Java 17 minimum and moving to Jakarta packages.

Some groups deliver their software to major organizations with their own pace of technology stack and are not ready (or yet willing) to move to Java 17 JDKs. You would be surprised how slow and bureaucratic these system can be in parallel to strict security policies.

Also moving to Jakarta is a major code upheaval. We (and I going on a limb to assume many other projects) do not yet know if beyond code/API changes between Spring 5/6 if all dependencies (and sub dependencies) in our project are yet with versions compliant with Jakarta.

EDIT: I am going to add that previous discussions on a 5 version were rejected due to break backwards compatibility. I would argue that Spring has warned not to used (and deprecated?) for years now so a 5.4 can be fair game. Also the critical CVE hanging over 5 already makes it unusable and a forced upgrade to Spring 6 for security also (naturally) break backward compatibility (as it is a proper right of a major release). So I personally think a final 5.4 release with HTTPInvoker removed will do a lot more good they any potential harm.

[bclozel]

Hello @act-amirsky

I'm sorry but we won't be releasing a new 5.4 generation and 6.0 is already out. Support timelines have been published a long time ago.

I understand that it will take time for many companies to upgrade to Spring Framework 6.0, but in this case improving the security process is the thing we all need to focus on.

On the Spring side, we're now part of VMware's CNA and have been working with the VMware security response team to improve our processes. This means that now a Spring CVE cannot be created without us being involved (unlike this one). We've also improved in many other ways and I believe we've shown that with the Spring4Shell CVE.

In the enterprise world, I think that the sources of information and processes should be improved as well. In this case, MITRE did not publish or calculate a CVSS score for CVE-2016-1000027. So maybe reviewing where the high score comes from and challenging this source of information in your security processes is a key point here.

We got an initial response back in August from the MITRE team. In our message, we underlined the time and resources consumed on this CVE and how this should need fixing. They replied the following (excerpt):

The CVE team does not feel that the existence of a CVE Record implies anything about whether it is worthwhile to expend time or resources to change the security behavior of a product. The information reported in the CVE-2016-1000027 description is likely to be relevant to some people, and the CVE description does not state that any default or recommended use case is inherently unsafe.

We understand that the mere existence of a CVE record can be a problem so we asked MITRE, back in August, to revisit the entry and mark it as resolved as of 5.3.0 where we officially deprecated the feature, sending an even stronger signal to developers. We didn't receive any response.

I can't think of any other way to improve the situation, despite our efforts.

[act-amirsky]

Awkward timing,

I posted an edit above to try to strengthen my "case" so I guess you may have missed it. I would not expect a full technical fix but suggest even aggressive removal of HTTP Invoker code is much more good than harm with justifications I mention just above in my "EDIT".

Don't get us wrong. We greatly appreciate the power and utility the Spring project has provided the world.

Final question/attempt then I guess this subject will need to rest. :( You provided a link on Support timelines and, unless I read it wrong, it states that OSS support (Free security updates and bugfixes with support from the Spring community.) for the 5.3.x branch lasts until 2024-12-31?

[bclozel]

I've just read your edit. I totally understand your concerns. From our perspective, retroactively releasing an unplanned 5.4 has a huge cost (maintenance, OSS and commercial support), all for a CVE record that's mostly a misunderstanding.

You provided a link on Support timelines and, unless I read it wrong, it states that OSS support (Free security updates and bugfixes with support from the Spring community.) for the 5.3.x branch lasts until 2024-12-31?

That is correct. Customers can also ask for additional backports until 2026-12-31; Spring artifacts are always published publicly on Maven Central.

[frankjkelly]

FYI Prisma is now complaining about this even though we are on spring framework 5.3.18

[2022-12-06T19:40:53.638Z] | CVE-2016-1000027 | critical | 9.80 | spring-core_spring-core                     | 5.3.18             | fixed in 6.0.0                   | > 2 years  | < 1 hour   | Pivotal Spring Framework through 5.3.16 suffers    | Yes               |
[2022-12-06T19:40:53.638Z] |                  |          |      |                                             |                    | 2 days ago                       |            |            | from a potential remote code execution (RCE) issue |                   |
[2022-12-06T19:40:53.638Z] |                  |          |      |                                             |                    |                                  |            |            | if used for Java deserialization of untrusted      |                   |
[2022-12-06T19:40:53.638Z] |                  |          |      |                                             |                    |                                  |            |            | data....                                           |                   |

[void-spark]

Great attempt to get everyone to update their Spring to 6.x with haste :)