How to resolve Spring RCE vulnerability(CVE-2022-22965)? - spring

Update
this issue is now assigned to CVE-2022-22965. Other than below nice answers, please do check Spring Framework RCE: Early Announcement as it is the most reliable and up-to-date site for this issue.
According to different source, seems we got a serious security issue when using Spring Core library.
https://securityboulevard.com/2022/03/new-spring4shell-zero-day-vulnerability-confirmed-what-it-is-and-how-to-be-prepared/
Quoting from above link, we are in risk if:
You use a Spring app (up to and including version 5.3.17)
Your app runs on Java 9+
You use form binding with name=value pairs – not using Spring’s more popular message conversion of JSON/XML
You don’t use an allowlist –OR– you don’t have a denylist that blocks fields like “class”, “module”, “classLoader”
The link suggested to some solution but doesn't seems easy to implement/reliable.
What should we do to fix this issue, in easiest and most reliable way?

According to the Spring Framework RCE: Early Announcement, upgrading to Spring Framework 5.3.18 or 5.2.20 will fix the RCE.
If you use Spring Boot, Spring Boot 2.5.12 and Spring Boot 2.6.6 fixes the vulnerability.
If you're unable to update:
You can choose to only upgrade Tomcat. The Apache Tomcat team has released versions 10.0.20, 9.0.62, and 8.5.78 all of which close the attack vector on Tomcat’s side.
If you can't do any of the above, the RCE announcement blog post suggests a workaround: Set disallowedFields on WebDataBinder through an #ControllerAdvice:
#ControllerAdvice
#Order(Ordered.LOWEST_PRECEDENCE)
public class BinderControllerAdvice {
#InitBinder
public void setAllowedFields(WebDataBinder dataBinder) {
String[] denylist = new String[]{"class.*", "Class.*", "*.class.*", "*.Class.*"};
dataBinder.setDisallowedFields(denylist);
}
}
This quick fix will not work if a controller sets disallowedFields locally through its own #InitBinder method, which overrides the global setting. Also, more generally, the workaround will not have an effect if you use alternate REST frameworks such as Jersey (however, it has not yet been demonstrated that such configurations are impacted).

Note: Spring upgrade is needed later on as vulnerability is not in Tomcat
Temporary Workaround is Upgrade tomcat to 10.0.20, 9.0.62, and 8.5.78
Spring Reference

Related

the spring boot oauth2 doc teaches deprecated annotation?

it's a confusing problem but suffered me several days.
Firstly, I got to know that the new spring security oauth2 is changed, then I come to learn:https://docs.spring.io/spring-security-oauth2-boot/docs/2.5.2/reference/html5/.
However, when I try to add the annotation #EnableAuthorizationServer to the "main method", the Intellij throws it's deprecated".
Then, I tried to check the version: springframework.boot:2.5.2 , spring-security-oauth2:2.5.1.RELEASE, spring-security-oauth2-autoconfigure:2.5.2.
It means all the dependencies are new, and the doc is new too.
Then why the Intellij says the annotation is deprecated? I just wanna follow the new trend. Please tell me what to do?
thanks a lot.
As the documentation to which you have linked states, the project is in maintenance mode. Where possible, it should not be used and the equivalent features in Spring Security 5.x should be used instead.
The deprecation message on EnableAuthorizationServer links to a migration guide. From there you can learn about the Spring Authorization Server project which you may want to use.

Why was Jasper support dropped out from Spring Framework 5.x?

We have been using Jasper with Spring Boot for our project's reporting feature but according to the Spring Framework 5.x release documentation Jasper support has been dropped out.
May I know why this has been done?
They have recommended to stay on Spring Framework 4.3.x in case we need Jasper support.
What if we want to upgrade to Spring Framework 5.x and still use Jasper, is there any alternative for doing so ?
Both parts of your question are answered in the JIRA ticket that tracked the support being dropped.
May I know why this has been done?
After some investigation, the new Exporter API in JasperReports is designed for upfront configuration in the form of ExporterInput / ExporterOutput objects, not lending itself to the piecemeal approach in Spring's JasperReports view class hierarchy and in particular not to the declarative configuration style typically used there. Even aside from that, we'd have to redesign our entire JasperReports view support in an severely incompatible way, due to the wide-ranging API changes across the JasperReports configuration model.
What if we want to upgrade to Spring Framework 5.x and still use Jasper, is there any alternative for doing so?
As a consequence, we rather recommend native use of the JasperReports API in Spring MVC handler methods, generating reports from specifically designed RESTful endpoints.
I had to upgrade to Spring 5 and this worked for me:
#GetMapping(value = "/report1")
public void getPdf(HttpServletResponse response) throws JRException, IOException {
InputStream jasperStream = this.getClass().getResourceAsStream("/jasperreports/HelloWorld1.jasper");
Map<String,Object> params = new HashMap<>();
JasperReport jasperReport = (JasperReport) JRLoader.loadObject(jasperStream);
JasperPrint jasperPrint = JasperFillManager.fillReport(jasperReport, params, new JREmptyDataSource());
response.setContentType("application/x-pdf");
response.setHeader("Content-disposition", "inline; filename=helloWorldReport.pdf");
final OutputStream outStream = response.getOutputStream();
JasperExportManager.exportReportToPdfStream(jasperPrint, outStream);
}
We have upgraded to Jaspersoft 6.8.1(Open Source) and Jaspersoft Pro 7.3.1 with Spring 5.1.20. We found below problems while upgrading:
Initially Font Extensions were not working. So, we created it
again using Jaspersoft 7.3.1 Studio.
There was a js file called jrs.configs.js which got introduced in Jasperreports Highcharts library was not loading because of which our Highcharts were not loading in embedded environment. We have put the file in the location where it was searching inside our web app. After that, everything is working.

Spring Data GemFire Region entry expiration (Time-To-Live) error

I have a Spring Data GemFire Region that's configured using annotations below:
#TimeToLiveExpiration(timeout = "100", action = "INVALIDATE")
#PartitionRegion(name = "blockedIPCache")
class BlockedIpEntityType { ... }
My application is a Spring Boot application and I used the following annotations to configure SDG:
#PeerCacheApplication
#EnableGemfireCaching
#EnableCachingDefinedRegions(clientRegionShortcut = ClientRegionShortcut.LOCAL, serverRegionShortcut = RegionShortcut.LOCAL)
#EnableStatistics
#EnableExpiration
#EnableEntityDefinedRegions(basePackageClasses = {...})
#EnableGemfireRepositories(basePackages = {...})
class GemFireConfiguration { ... }
All I want is to insert an object using a Spring Data GemFire Repository and after awhile the entry will be invalidated.
But, I face this Exception when I start my application...
Caused by: java.lang.IllegalStateException: Cannot set idle timeout when statistics are disabled.
at org.apache.geode.internal.cache.AbstractRegion.setCustomEntryIdleTimeout(AbstractRegion.java:1157) ~[geode-core-9.1.1.jar:?]
at org.springframework.data.gemfire.config.annotation.ExpirationConfiguration$ExpirationPolicyMetaData.configure(ExpirationConfiguration.java:511) ~[spring-data-gemfire-2.0.6.RELEASE.jar:2.0.6.RELEASE]
at org.springframework.data.gemfire.config.annotation.ExpirationConfiguration$1.postProcessAfterInitialization(ExpirationConfiguration.java:160) ~[spring-data-gemfire-2.0.6.RELEASE.jar:2.0.6.RELEASE]
...
This happens exactly when Spring tries to autowire my Repository related to the Region configured above.
So what I'm doing wrong? And, is there a way to enable Region statistics using Java configuration or Annotations?
Note: Using Spring Data GemFire 2.0.6, Spring 5.0.5, Spring Boot 2.0.1 used in the project.
It turns out, you did not do anything wrong. Unfortunately, you stumbled across a bug(!), for which I have already filed SGF-747 and fixed. I am sorry for the inconvenience this issue may have caused you.
We are planning a Spring Data Lovelace M3 (Milestone 3) release tomorrow (Thursday, 5/17, CET). The release schedule is visible from Spring Release Calendar. All dates are tentative.
As such, you could try the new Spring Data for Pivotal GemFire (SDG) Lovelace bits (i.e. 2.1.0.M3) with the fix. SDG 2.1.0. should work just fine with Spring Boot 2.0.1/2.RELEASE and Spring 5.0.5/6.RELEASE.
However, if you are expecting to get GA bits for SDG containing this fix, then you will have to wait for the next Spring Data Kay Service Release (Kay SR8), or the Spring Data for Pivotal GemFire 2.0.8 Service Release. I am backing porting this fix.
Unfortunately, there is not another Spring Data Kay Service Release (i.e. Kay SR8) planned until probably around July 2nd or 3rd, right after Spring Framework 5.0.7 is released on Monday, July 2nd and just before Spring Boot 2.0.3 is released on Wednesday, July 4th, which is usually when we plan Spring Data Service Releases. Also, know that Spring Boot 2.0.x is based on Spring Data Kay, but should work just fine with SD Lovelace too, as I mentioned previously.
In the meantime, I will try to think of workaround where the convenience of the Annotations (e.g. #EnableEntityDefinedRegions) can still be used. I will post the workaround in SGF-747.
I see that you specified the clientRegionShortcut attribute in the #EnableCachingDefinedRegions annotation but have declared your application to be a #PeerCacheApplication. While there is no harm in doing so, the clientRegionShortcut attribute is useless in this case. Likewise, the serverRegionShortcut attribute would have no meaning if you are application were a #ClientCacheApplication instead; something to keep in mind.
Lastly, I wanted to let you know that the SDG #EnableStatistics annotation does not have the effect you probably think it does.
Specifically, SDG's #EnableStatistics annotation is concerned with enabling Pivotal GemFire's statistics "sampling" as explained here, which is configured by doing this, as also explained in the SDG #EnableStatistics annotation Javadoc, as well as referenced in the SDG Reference Guide.
The "statistics enabling" that ultimately needs to happen is by setting the Region's staticsEnabled attribute property when configuring and creating the Region (e.g. "blockedIPCache").
That is exactly what the #EnableExpiration annotation will indirectly guarantee now, with the fix in SGF-747, without the need to #EnableStatistics.
Anyway, I hope this all makes sense and helps.
Regards,
John

Where is this class "HttpContext" exist in glassfish jersey 2.9?

Where is this class "HttpContext" exist in glassfish jersey 2.9 . I was using jersey 1.17.1 to use HttpContext where it was exist in package com.sun.jersey.api.core.HttpContext.
But i did't find it in jersey 2.9.
The direct replacement for HttpContext is not available in Jersey 2.x versions and unfortunately, this breaking change detail hasn't been mentioned anywhere in the migration guide. Instead of searching for direct replacement, if we dig deeper into the interface HttpContext, based on the following method summary refer
we can infer that instead of using HttpContext, we can simply use the following out-of-the-box alternatives.
Instead of HttpContext#getRequest use #Context ContainerRequestContext crc
Instead of HttpContext#getResponse use #Context ContainerResponseContext crc
Instead of HttpContext#getUriInfo use #Context UriInfo uriInfo
Instead of HttpContext#getProperties use ContainerRequestContext#getProperty
Jersey 2.x had a lot of breaking changes, which partly caused by the fact that JAX-RS standard incorporated a lot of things in Jersey 1.x.
To quote https://jersey.java.net/documentation/latest/migration.html#mig-1.x
This chapter is a migration guide for people switching from Jersey 1.x. Since many of the Jersey 1.x features became part of JAX-RS 2.0 standard which caused changes in the package names, we decided it is a good time to do a more significant incompatible refactoring, which will allow us to introduce some more interesting new features in the future. As the result, there are many incompatibilities between Jersey 1.x and Jersey 2.0. This chapter summarizes how to migrate the concepts found in Jersey 1.x to Jersey/JAX-RS 2.0 concepts.
The migration chapter does not indicate what happened to HttpContext, but it no longer exists in its old form.

Grizzly and Jersey are hiding my other annotations

we have to update a Spring project where we need to embed a https server which supports SSL protocols and cipher suites selection.
My setup is : Spring 3.2.4, jersey 1.15.1 and Grizzly 1.9.60
The main problem that our resource class is calling some components which are expecting annotations. But Grizzly seems to ignore the non-jersey REST annotations. So my custom annotations aren't transmitted at all.
I was wondering if you can give a an idea on how to work past this:
is it possible to configure Jersey so it won't use annotations (maybe a xml or java config), hopefully keeping my own annotations to be transmitted down the line ?
or it is possible to manually add the annotations on the method call ?
I recently tried this with Jetty 1.9.2 and jersey2 and it seems I have the same result. The only thing that worked was a SimpleServerFactory from Jersey 1, but like I said it didn't provide customizable SSL parameters.
Please someone :) ...
OK, just posting here maybe it will help someone. I finally got my hands on the components code and I noticed that the called class was looking for annotations in the last three stack traces.
What happened was Grizzly was adding a proxy of some kind, and that causes the three stack traces not to be enough and the annotations were not sent through.

Resources