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
Comment From: bclozel
This been addressed already in the documentation, as explained in the report you've copy/pasted here: see the reference documentation.
Comment From: 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
Comment From: 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.
Comment From: 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.
Comment From: 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.
Comment From: tgit24
I think spring team should contact NVD to know why this vulnerability all the sudden get raised to 9.8 ??
Comment From: rstoyanchev
@tgit24 this has already been answered above.
Comment From: 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.
Comment From: 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?
Comment From: 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.
Comment From: bclozel
This will be addressed in #25379
Comment From: 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.
Comment From: 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-webmvcand Spring WebFlux isspring-webflux.spring-webis the shared infrastructure for both Web Frameworks. A WebFlux app still depends onspring-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).
Comment From: 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
Comment From: 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.
Comment From: 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.
Comment From: 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.
Comment From: 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?
Comment From: 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?
Comment From: 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.
Comment From: jpcmonster
In the short term it may cause more noise though; OWASP DependencyCheck began sounding the alarm in our CI a few hours ago.
Comment From: 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.
Comment From: 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.
Comment From: 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!
Comment From: ghost
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.
Comment From: 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.
Comment From: 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).
Comment From: 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.
Comment From: 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.
Comment From: 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
HttpInvokerServiceExporterin 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.
Comment From: 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?
Comment From: 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.
Comment From: 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.
Comment From: 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?
Comment From: 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.
Comment From: 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?
Comment From: bclozel
@ecroys this has been adresses in this comment already: https://github.com/spring-projects/spring-framework/issues/24434#issuecomment-744519525
Comment From: 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.
Comment From: 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.
Comment From: 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
Comment From: 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!
Comment From: 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.
Comment From: 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?
Comment From: 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.
Comment From: 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.
Comment From: 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.
Comment From: 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?
Comment From: 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.
Comment From: 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.... | |
Comment From: void-spark
Great attempt to get everyone to update their Spring to 6.x with haste :)
Comment From: YSavanier
Great attempt to get everyone to update to Java 17 may I add, that's not really the same as a dependency version change ^^;
As it is indeed a natural thing to update one's JDK version in due time, keep in mind all organisations can't keep up with the version unroll, and asking everyone to change their JVM running on their infrastructure servers OS that might not have it in their package repository cause it was released just a year ago, all just because there is a CVE in a library which will not be adressed by the editor isn't easy to accept.
Working in such environment I should say this is a dead end here, our security department doesn't accept our argument about the CVE being on a class that we don't use and order us to update the dependency (which we can't cause our system department hasn't migrated their redhat version to one that propose the jdk17 yet and refuse to install anything outside it) or remove it without delay (which we can't cause, well... that one is obvious ^^;).
Soooo as it is the only CVE remaining on ours applications and with a critical 9.8 score, I might simply add that's a first time here not being able to mitigate it in any way, not because the library is too old or doesn't have any active maintainer, but only because of pure dogmatism about what a minor version release can or should be able to adress concerning security alerts.
Cheers,
Comment From: act-amirsky
I have been maintaining a long and friendly discussion with @bclozel on this topic and I can see the perspective on both sides. One core issue is that HTTP Invoker is essentially deprecated but "fixing" it is by removing - which I can understand is usually the prerogative of a major release and is what Spring 6 effectively did. The concern on Spring 5 is that removing breaks backward compatibility and API for whoever on the planet (and there are a lot of Spring adoptions) happened to be using this feature.
Let me put a toe into the discussion a last, last time to offer a possible way out here. I will duck and cover after suggesting.
What if the Spring project did not remove the HTTP Invoker - but instead added a blocking control that disables the functionality. It will be disabled by default and can be re-enabled with a one-line property flag for those few who still use HTTP Invoker. I am surmising the noise of the 9.8 CVE is much greater than the possible noise of needing to add a flag to restore deprecated functionality.
Hopefully, the fact that the library by default does not expose the vulnerability would be enough to close the CVE or at least greatly reduce its CVSS score?
Comment From: bclozel
@act-amirsky as you've seen in https://github.com/spring-projects/spring-framework/issues/24434#issuecomment-1317007089, at this point it's not even about whether there's an actual security issue but this entry acts as "relevant information" for developers. Of course, CVE entries are not considered like that by our industry and this is causing the current discussion.
What if the Spring project did not remove the HTTP Invoker - but instead added a blocking control that disables the functionality. It will be disabled by default and can be re-enabled with a one-line property flag for those few who still use HTTP Invoker
The feature itself has always been opt-in, has come with a strong warning for a very long time and has been formally deprecated since 5.3. We've made that point already and this wasn't enough to get that entry suppressed. Adding another opt-in flag is not likely to change anything there unfortunately.
As for the 9.8 score, let me underline again that this was never published by MITRE on the official entry and that this was contributed by NVD independently. We could of course challenge this score, but I don't think that the CVSS score includes whether it requires knowledge and an informed decision from the developer to be exposed to this risk.
Thanks for keeping the discussion constructive and understanding our perspective @act-amirsky.
Comment From: Jos31fr
@bclozel
As for the 9.8 score, let me underline again that this was never published by MITRE on the official entry and that this was contributed by NVD independently. We could of course challenge this score, but I don't think that the CVSS score includes whether it requires knowledge and an informed decision from the developer to be exposed to this risk.
I think it is taken in account, otherwise any java application will be considered at risk due to reflect possiblities.... If this feature is opt-in, the CVSS score should not be 9.8
The main problem is that CVSS score take into account damage but not potential occurence. If we only take damage into account we should all live in a anti nuclear bunker...
Comment From: bclozel
@Jos31fr Feel free to suggest an alternate CVSS score using the generator: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator
Comment From: dkykuta
With all due respect, may I ask how can the version 5.3 be supported until 2024 if this 9.8 scores makes it unusable for some (maybe most?) of us? What is the plan here?
Comment From: bclozel
@dkykuta we've challenged this report and still believe it is invalid. By the same logic, how can anyone be using Java in production when Java deserialization from untrusted sources is very much applicable to all? We're also challenging this score (calculated by the NVD, independently of the official CVE entry), also unsuccessfully so far.
If we were to remove the offending classes from 5.3.x, we would:
- not fix the underlying problem as Java deserialization can be performed without Spring being involved
- break all users using
HttpInvokerServiceExporterwith trusted input (as it's expected) and cut them from any real CVE fix in the future - silence security tools about this particular issue, whereas most people bothered by it are not using
HttpInvokerServiceExporterat all
Anyone here can suggest improvements for this entry to the MITRE team by using the official form.
Comment From: dkykuta
@bclozel Thank you for your answer. Most companies cannot verify project by project if it is using some class or not. They can only go as far as checking the dependencies and related vulnerabilities. I agree with you in that it would not fix the underlying problem, but it would mitigate the way this package exposes it and thus this CVE.
We are part of the people you mentioned. We don't use HttpInvokerServiceExporter but our security department is asking of us to "resolve" this critical vulnerability. They don't care if we are using this class or not. It is in the classpath, security tools are complaining about this, and they don't want that.
We cannot upgrade to java 17 just yet, and we don't know what to do. Does anyone have an alternative besides upgrading everything asap?
Comment From: frankjkelly
I see both sides of this issue but I think Pivotal / Spring are better situated to leverage their position to help the very many teams and organizations impacted by this. This seems very like the December 2021 log4j debacle all over again (a big change going into holiday time for a lot of folks) and thankfully there Spring had great support and great hooks to help us get through that experience. Appreciate any assistance you can give. Thank you!
Comment From: jnizet
Throwing an idea here: if the HttpInvokerServiceExporter is not used, but the class absolutely needs to be removed from the jar, how about doing just that: remove it from the jar? I.e. repackage the jar, store it under a different GAV in your company's repository, and use that repackaged library instead of the original jar.
Comment From: bclozel
@dkykuta I know for a fact that it's impossible for any organization to have the expertise for all technologies listed in CVE entries. But it doesn't mean that one should only look at GAV coordinates and the CVSS score - especially when the main report doesn't contain any CVSS score and the content of the advisory is much more nuanced.
Your can suggest your security department to: * reach out to our security team to discuss the matter * read the Spring team's position in this issue * read independent security analysis * contact their security tool vendor about this false positive * challenge the report if they think that CVE entries should be enforceable through tooling and should never be informational as it is for this one
@jnizet I think that most security tools look at dependency GAVs and do not care about Jar contents. It's easy to work around an actual CVE: you can just shade the vulnerable dependency.
Comment From: Jos31fr
@dkykuta we've challenged this report and still believe it is invalid. By the same logic, how can anyone be using Java in production when Java deserialization from untrusted sources is very much applicable to all? We're also challenging this score (calculated by the NVD, independently of the official CVE entry), also unsuccessfully so far.
What is the mean time of this procedure? If they completely reject your demand, have you any other plan to mitigate the issue? (like put this class in another artifact)
Comment From: Nikhilkarande33
@bclozel Will Vulnerability CVE-2016-1000027 for spring-web be fixed in 5.3.25?
I can see 5.3.25 will release in January 2023.
We can see latest non-vulnerable version is 6.0.1 but it requires java 17 upgrade which is not feasible for us at this moment.
Please suggest.
Comment From: bclozel
@bclozel Will Vulnerability https://github.com/advisories/GHSA-4wrc-f8pq-fpqp for spring-web be fixed in 5.3.25?
No, see https://github.com/spring-projects/spring-framework/issues/24434#issuecomment-744519525
Comment From: nate-biles
@bclozel How is HttpInvokerServiceExporter loaded as a bean? I'm wondering if it's even used. I don't see it being created directly, nor any methods called on it. It also has no @Component and it's not found in any configuration, also not used in spring.factories - how is it even loaded? Is there some other spring project I'm not using that loads it?
Comment From: bclozel
@nate-biles by default, it's not. The application itself needs to declare it as a bean to enable this support.
Comment From: dmitry-weirdo
==========
Total: 1 (CRITICAL: 1)
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฌโโโโโโโโโโโโโโโโโโโฌโโโโโโโโโโโฌโโโโโโโโโโโโโโโโโโโโฌโโโโโโโโโโโโโโโโฌโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
โ Library โ Vulnerability โ Severity โ Installed Version โ Fixed Version โ Title โ
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโผโโโโโโโโโโโโโโโโโโโผโโโโโโโโโโโผโโโโโโโโโโโโโโโโโโโโผโโโโโโโโโโโโโโโโผโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโค
โ org.springframework:spring-web (spring-web-5.3.24.jar) โ CVE-2016-1000027 โ CRITICAL โ 5.3.24 โ 6.0.0 โ spring: HttpInvokerServiceExporter readRemoteInvocation โ
โ โ โ โ โ โ method untrusted java deserialization โ
โ โ โ โ โ โ https://avd.aquasec.com/nvd/cve-2016-1000027 โ
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโดโโโโโโโโโโโโโโโโโโโดโโโโโโโโโโโดโโโโโโโโโโโโโโโโโโโโดโโโโโโโโโโโโโโโโดโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
This CVE started to fail now on spring-web-5.3.24.jar. The project cannot be yet migrated to Spring Boot 3 because of several bugs.
Should we โ as it is always said by Spring for each and every CVE we post โ ignore this CVE again?
Comment From: bclozel
@dmitry-weirdo nothing has changed on the CVE as far as I know. Maybe your tool changed how its detection mechanism work? You should contact the tool vendor about that. You should not ignore this CVE if your application is deserializing untrusted content.
Comment From: dmitry-weirdo
@bclozel Indeed, thanks for pointing out, this CVE should be already ignored for the dependency-check-maven that we use. It starts to fail again after a major version switch of this maven plugin.
https://github.com/jeremylong/DependencyCheck/issues/5331 โ I added a ticket in the plugin's repo.
Comment From: DRoppelt
I would like to share our workaround that we did in our organization where we have our own repository mirror. We download the jar, unpack it, drop the offending classes and repackage it as a different version. Similar to how some here have requested pivotal to do it in the official jar. We then customized our CVE reporting with "if you find the CVE in a jar that has this patchversion, it is a false positive"
The assumption is that the developers who have the largest issue with this CVE (as a false positive for their services)
a) are also going to be the ones that are a large (and inflexible) organization b) that therefore also hosts their own repository (Nexus, JFrog, etc.).
So I think this is worth sharing with everyone.
Here is a snippet of our pipeline (Jenkins):
stage('Download original jar') {
steps {
sh "rm -rf target"
mvn("org.apache.maven.plugins:maven-dependency-plugin:3.4.0:copy \
-Dartifact=org.springframework:spring-web:${springWebVersion}:jar \
-DoutputDirectory=target")
}
}
stage('Unpack&patch') {
steps {
script {
dir("target") {
sh "jar xvf spring-web-${springWebVersion}.jar"
sh "rm -f spring-web-${springWebVersion}.jar"
sh "rm -rf org/springframework/remoting/httpinvoker"
sh "jar cf file.jar *"
}
}
}
}
stage('Upload patch to nexus') {
steps {
mvn("deploy:deploy-file" +
" -Dfile=target/file.jar" +
" -DgroupId=org.springframework" +
" -DartifactId=spring-web" +
" -Dversion=${springWebVersion}.patchCVE-2016-1000027v${patchIteration}" +
" -Dpackaging=jar" +
" -Durl=https://yourartifactrepo/repository/releases" +
" -DrepositoryId=repo-id-with-credentials"
)
}
}
Comment From: accnetodevel
@DRoppelt, could we have unexpected spring-web behavior when removing http-invoker?
Comment From: DRoppelt
@accnetodevel my understanding is that all classes in there are opt-in and wont come with any auto-configuration. You will have unexpected bevaviour if you are indeed using httpinvoker. I have not seen any issues with basic spring-web usage (simple CRUDs or spring-web solely present for Actuator endpoints).
Comment From: starseedph
I would like to share our workaround that we did in our organization where we have our own repository mirror. We download the jar, unpack it, drop the offending classes and repackage it as a different version. Similar to how some here have requested pivotal to do it in the official jar. We then customized our CVE reporting with "if you find the CVE in a jar that has this patchversion, it is a false positive"
The assumption is that the developers who have the largest issue with this CVE (as a false positive for their services)
a) are also going to be the ones that are a large (and inflexible) organization b) that therefore also hosts their own repository (Nexus, JFrog, etc.).
So I think this is worth sharing with everyone.
Here is a snippet of our pipeline (Jenkins):
stage('Download original jar') { steps { sh "rm -rf target" mvn("org.apache.maven.plugins:maven-dependency-plugin:3.4.0:copy \ -Dartifact=org.springframework:spring-web:${springWebVersion}:jar \ -DoutputDirectory=target") } } stage('Unpack&patch') { steps { script { dir("target") { sh "jar xvf spring-web-${springWebVersion}.jar" sh "rm -f spring-web-${springWebVersion}.jar" sh "rm -rf org/springframework/remoting/httpinvoker" sh "jar cf file.jar *" } } } } stage('Upload patch to nexus') { steps { mvn("deploy:deploy-file" + " -Dfile=target/file.jar" + " -DgroupId=org.springframework" + " -DartifactId=spring-web" + " -Dversion=${springWebVersion}.patchCVE-2016-1000027v${patchIteration}" + " -Dpackaging=jar" + " -Durl=https://yourartifactrepo/repository/releases" + " -DrepositoryId=repo-id-with-credentials" ) } }
@DRoppelt So after removing it from the package, how did you reimplement it if you application is using httpinvoker? Thanks :)
Comment From: DRoppelt
@starseedph the workaround assumes that you do not need anything the httpinvoker provided. Code that does not exist cannot be exploited. It is more or less mimicking what happened for spring-framework 6.X: it is now removed.
We did not reimplement it as I we are just not using it. We do everything by REST or as interactive HTML pages, no RMI/remoting.
Comment From: qlwszl
็ปไปถ่ฏฆๆ (spring-framework-5.3.26),ๆชๆญขๅฐ็ฎๅ๏ผ่ฟๆๅทฅๅ ท่ฟๅจๆฅๅบๆ้ซๅฑๆผๆด๏ผhttps://nvd.nist.gov/vuln/detail/CVE-2016-1000027ใไธ็ฅ้ๆผๆดๆฏๅฆ่ฟๅญๅจใ
Comment From: bclozel
@qlwszl this is only a security issue if the component is used in an unsafe way (e.g. using untrusted input). For more details, see https://github.com/spring-projects/spring-framework/issues/24434#issuecomment-744519525
Comment From: aakarshsingh
BTW, the documentation that is kept quoted over and over again in this thread now leads to a broken link.
https://docs.spring.io/spring-framework/docs/current/spring-framework-reference/integration.html#remoting-httpinvoker
EDIT: Can be accessible through 5.x tags
https://github.com/spring-projects/spring-framework/blob/v5.3.27/src/docs/asciidoc/integration.adoc#remoting-httpinvoker
Comment From: arsadali
@starseedph the workaround assumes that you do not need anything the httpinvoker provided. Code that does not exist cannot be exploited. It is more or less mimicking what happened for spring-framework 6.X: it is now removed.
We did not reimplement it as I we are just not using it. We do everything by REST or as interactive HTML pages, no RMI/remoting.
So your solution is accepted by the organization and treating this as a fix?
Comment From: DRoppelt
So your solution is accepted by the organization and treating this as a fix?
yep. Cannot exploit a remoting CVE if the classes do not exist. In a way, it is a self-made backport of the fix in 6.X
Comment From: act-amirsky
Unfortunately, this would not satisfy everyone in the industry. Many big organizations rely on 3rd security vendors like BlackDuck or WhiteSource. BlackDuck would not recognize a mitigated version unless there was officially some public release made by someone. Such a release would relieve a lot of tension and pressure. Moving to Spring 6 is the ultimate solution of course but it comes with new requirements which are not easy for all clients of a vendors software to quickly adhere to (example Java 17) โ so will take a long time to move over.
Comment From: DRoppelt
BlackDuck would not recognize a mitigated version
sounds like an issue between big organizations and providers of rudimentary scanning tools that should not be taken at face value. A JdbcTemplate allows me to inject "DROP TABLE X" from input if not used correctly, but for some reason that is not a >9.0 CVE in all jdbc-esque libraries.
If you are using these tools without a way to overrule their results (i.e. allowing whitelisting their supposed findings), you keep busy for non-issues. This comment summarizes it quite well IMO https://github.com/spring-projects/spring-framework/issues/24434#issuecomment-744519525
Comment From: akash-saha-jmh
Is there any plan to fix this cve on spring 5.x version?
Comment From: atom888888
Right now NVD says that the "vendor's position" (presumably Spring) is that this is a non issue and won't be changed:
https://nvd.nist.gov/vuln/detail/cve-2016-1000027
"CVE-2016-1000027 Detail Modified This CVE record has been updated after NVD enrichment efforts were completed. Enrichment data supplied by the NVD may require amendment due to these changes.
Description Pivotal Spring Framework through 5.3.16 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. NOTE: the vendor's position is that untrusted data is not an intended use case. The product's behavior will not be changed because some users rely on deserialization of trusted data."
Comment From: atom888888
Under "xray" vulnerability scanning tool it's flagging it for some reason? It wasn't doing it a day or so ago and it's now suddenly showing up as an issue under Xray:
Security Violations โโโโโโโโโโโโฌโโโโโโโโโโโโโโโโโโโโโโโโโโโโฌโโโโโโโโโโโโโฌโโโโโโโโโโโโโโโโโโโโโโโโโโโโฌโโโโโโโโโโโโโฌโโโโโโโโโโโฌโโโโโโโโฌโโโโโโโโโโโโโโโโโโโ โ SEVERITY โ DIRECT โ DIRECT โ IMPACTED โ IMPACTED โ FIXED โ TYPE โ CVE โ โ โ DEPENDENCY โ DEPENDENCY โ DEPENDENCY โ DEPENDENCY โ VERSIONS โ โ โ โ โ โ VERSION โ NAME โ VERSION โ โ โ โ โโโโโโโโโโโโผโโโโโโโโโโโโโโโโโโโโโโโโโโโโผโโโโโโโโโโโโโผโโโโโโโโโโโโโโโโโโโโโโโโโโโโผโโโโโโโโโโโโโผโโโโโโโโโโโผโโโโโโโโผโโโโโโโโโโโโโโโโโโโค โ Critical โ org.springframework:sprin โ 5.3.38 โ org.springframework:sprin โ 5.3.38 โ [6.0.0] โ Maven โ CVE-2016-1000027 โ โ โ g-web โ โ g-web โ โ โ โ โ โโโโโโโโโโโโดโโโโโโโโโโโโโโโโโโโโโโโโโโโโดโโโโโโโโโโโโโดโโโโโโโโโโโโโโโโโโโโโโโโโโโโดโโโโโโโโโโโโโดโโโโโโโโโโโดโโโโโโโโดโโโโโโโโโโโโโโโโโโโ
Comment From: bclozel
@atom888888 If you believe this needs to be updated, please reach out to the Xray team as we cannot change this.