I came across an article Open source library with vulnerabilities.
This article states that
"Spring Expression Language (SpEL) could be exploited through HTTP parameter submissions that would allow attackers to get sensitive system data, application and user cookies."
Can someone shed more light on this, please ?
The discovery by Aspect Security was found in January 2013, but the fix that SpringSource published was made available back in 2011 when this was first discovered. Dan Amodio of Aspect Security informed SpringSource about the possibility of remote code execution.
SpringSource updated our security report 12-06-2012 with Aspect Security’s finding – but the fix/mitigation listed in the original advisory is still applicable: http://support.springsource.com/security/cve-2011-2730
This vulnerability only affects Spring Framework versions:
• 3.0.0 to 3.0.5 -- upgrading to 3.0.6 here would solve the issue.
• 2.5.0 to 2.5.6.SEC02 (community releases) -- upgrading to 2.5.6.SEC03 here would solve the issue.
• 2.5.0 to 2.5.7.SR01 (subscription customers) -- upgrading to 2.5.7.SR02 here would solve the issue.
This has been fixed in all versions going forward – the current release of SpringFramework is 3.2, released in Dec 2012.
Thanks,
-Pieter (SpringSource)
Checkout this Aspect Security/Minded Security evaluation of SpEL (google docs link) which the article you link to is probably referring (for the specific case of SpEL).
They describe how certain spring JSP tags double evaluate EL expressions. In these cases it may be possible for the user to submit data to the server in the form of SpEL e.g. as a request parameter with value ${bean.val} (URL encoded)
http://...?exp=$%7Bbean.val%7D
Inside JSP pages, the expression ${param.exp} will be resolved to the text ${bean.val} which by itself is safe. If however, that expression resides within an attribute of a spring JSTL tag, that resolved value may be evaluated again e.g. in the spring:message tag:
<spring:message message="${param.exp}" />
will result in the value ${bean.val} being passed through to the spring:message tag which will evaluate the bean.getVal() method. Hence we now have code submitted by the client and being run on the server.
Related
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
My company's Sonatype scan shows Spring-Web is vulnerable even for the latest version (currently 5.2.3.RELEASE).
It reads:
"Found security vulnerability CVE-2016-1000027 with severity 9.8".
I noticed CVE-2016-1000027 is added to the NATIONAL VULNERABILITY DATABASE
on 01/02/2020, and it is in regards to
"Spring Framework 4.1.4 suffers from a potential remote code execution
(RCE) issue if used for Java deserialization of untrusted data".
Is this an obsolete ticket or has it not be resolved after 4 years?
This issue is resolved from a Spring Framework point of view, see my latest comment summarizing the situation on that issue. Your application is only vulnerable if you're using HTTPInvokerServiceExporter or RemoteInvocationSerializingExporter and reading data from untrusted sources.
Deserializing Java code from untrusted sources is a well-known problem in Java (so, all Java applications and Frameworks!), and this feature might be removed in future Java versions.
Given the nature of this security problem (there's no way to "fix it" besides removing the classes, which will be done in the next major version of Spring Framework), contacting your vendor or your security team is the best course of action. The Spring team is happy to help the community with this matter by providing more context on that issue if needed.
We have projects using Struts 2.0 and 2.1.
We're using web-hosting with Tomcat and both projects are working fine on remote servers. Recently, we got warning message from the webhosting provider, like:
This notice is inform you that recently numerous vulnerabilities have been discovered related to Struts and Struts2 frameworks and other frameworks which use OGNL classes.
Since your application is using Struts or Struts2 framework, we HIGHLY recommend that you URGENTLY update it to the most recent version: Struts v2.3.16.1
After research, we found there're consistent upgrades:
http://struts.apache.org/announce.html
Therefore, we tried to upgrade our Struts2 to 2.3.16.3 (latest version at present). However, we found it's not a trivial task to upgrade Struts2, since everything doesn't work, including AJAX tags, AJX form submit, auto-complete, etc. In this sense, Struts 2 is not well designed for scalability.
One example is that whenever we submit our AJAX form, the result will be in a new page instead of in the targets field defined in the sx:submit or sj:submit tag. We don't want to re-write all the codes just because of the upgrade.
We want to know if we don't upgrade Struts2 to the latest version, what kind of vulnerabilities our web application will face. Could anyone give us more details or any hint for solutions based on our situation? Thanks so much.
You are probably looking for Security Bulletins. Each documents describe the summary, problem, and solution to resolve the problem. At the end of each document you can find hotfixes if they are available.
One example is that whenever we submit our ajax form, the result will
be in a new page instead of in the targets field defined in the
sx:submit or sj:submit tag.
It seems you are using struts2 and struts 2 jquery plugin, so try to update to struts 2 jquery 3.7.0 too.
I recommend to accept some reworks and upgrade as some security issues are high.
There are some key parts which has changed and may need to be considered during upgrade like acceptableParameterName. Also review your param interceptor stack and list of exclude parameters.
I moved a JSF application from Galssfish 3.1.2 to Glassfish 4.0 and I thought the new server release was completely back compatible.
I found out it is not.
I used an outdated library, Primefaces 2.X, and some components stopped working properly, at least <p:tabview>. Common sense suggests to pass to a newer library such as Primafaces 3.5, but that way I have to modify my xhtml pages. Cannot find a compatibility matrix anywhere, nor a migration tutorial. Can you help ?
There is at least another weird problem outside those related to the Primefaces library.
I have a quite complex page and till now I couldn't isolate the problem to a simpler scenario.
In this page I have an <ui:repeat> tag and then a form with a button.
The button is configured to send Ajax request and update (render) only a single ui component.
At the 3rd Ajax request it stops working and I get an error saying there is a duplicate ID corresponding to the <ui:repeat> tag.
Any idea ?
Is there a migration guide from Glassfish 3.1.2 to Glassfish 4.0 which gives hints on what has changed and how to modify existing applications ?
Update
I found the following post which deals about the last problem I'm talkin about
Component ID xxx has already been found in the view.
Unfortunately I cannot understand how to solve it despite it has an accepted answer !
This is one of the many bugs that were released with GF4.
I would suggest either waiting for the next release of GF (if you need a released version) or update GF to the latest JSF release (Currently 2.2.8 I think).
JSF implementation jars
JEE7 APIs
JSF current and older bugs
I am considering to utilize Expression-Based Access Control from Spring Security 3.0.
The documentation says: You can access any of the method arguments by name as expression variables, provided your code has debug information compiled in.
That means that I have to have debug info left in my production wars and jars to properly use Expression-Based Access Control. For me it seems not very good idea at all.
Please tell me your opinions on this issue, so I can summarize your expirience to deside where I go for it or not.
Thank you in advance!
Max
It is a little strange, but this isn't tied to Spring Security. Spring Web MVC uses it too; e.g., to discover #RequestParam and #PathVariable default values.
In my experience people typically leave debug information in their builds (even production builds) to support troubleshooting (debug level logging is a different story), so Spring takes advantage of this. But it's fair to say that Spring is violating the principle of least surprise here, meaning that one wouldn't expect turning debug info off to turn a working app into a broken app.
Please see Spring security annotations with EL — requires debug information compiled in?