Description

When configured to enable default typing, Jackson contained a deserialization vulnerability that could lead to arbitrary code execution. Jackson fixed this vulnerability by blacklisting known "deserialization gadgets".

Spring Security configures Jackson with global default typing enabled which means that through the previous exploit, arbitrary code could be executed if all of the following is true:

• Spring Security’s Jackson support is being leveraged by invoking SecurityJackson2Modules.getModules(ClassLoader) or SecurityJackson2Modules.enableDefaultTyping(ObjectMapper)
• Jackson is used to deserialize data that is not trusted. Spring Security does not perform deserialization using Jackson, so this is an explicit choice of the user.
• There is an unknown (Jackson is not blacklisting it already) “deserialization gadget” that allows code execution present on the classpath

Jackson provides a blacklisting approach to protecting against this type of attack, but Spring Security should be proactive against blocking unknown “deserialization gadgets” when Spring Security enables default typing.

Affected Spring Products and Versions

• Spring Security 4.2.0.RELEASE - 4.2.2.RELEASE
• Spring Security 5.0.0.M1

Mitigation

Users of affected versions should apply the following mitigation:

• Releases that have fixed this issue include: <ul><li>Spring Security: 4.2.3.RELEASE+</li><li>Spring Security: 5.0.0.M2+</li></ul>
• The fix ensures that by default only explicitly mapped classes will be deserialized. The effect of using explicitly mapped classes is to create a whitelist which works with all supported versions of Jackson. If users explicitly opt into <a href='https://github.com/FasterXML/jackson-docs/wiki/JacksonPolymorphicDeserialization#11-global-default-typing'>global default typing</a>, the previous potentially dangerous configuration is restored.

References

• https://github.com/FasterXML/jackson-databind/issues/1599
• https://github.com/FasterXML/jackson-docs/wiki/JacksonPolymorphicDeserialization#11-global-default-typing
• https://github.com/spring-projects/spring-security/issues/4370
• http…

Description

Applications that do not change the value of the MvcViewFactoryCreator useSpringBinding property which is disabled by default (i.e. set to “false”) can be vulnerable to malicious EL expressions in view states that process form submissions but do not have a sub-element to declare explicit data binding property mappings.

Affected Spring Products and Versions

• Spring Web Flow 2.4.0 to 2.4.4
• Older unsupported versions are also affected

Mitigation

Users of affected versions should apply the following mitigation:

• 2.4.x users should upgrade to 2.4.5
• Note that generally it is a good practice and recommended to always use explicit data binding declarations in view states in order to prevent form submissions from setting fields on the target object that should not be set.
• Spring Web Flow with JSF users are not impacted by this report.

Credit

The issue was identified by Stefano Ciccone of Gotham Digital Science

References

• <a href='https://jira.spring.io/browse/SWF-1700'&gt;https://jira.spring.io/browse/SWF-1700&lt;/a>
• <a href='https://github.com/spring-projects/spring-webflow/commit/57f2ccb66946943fbf3b3f2165eac1c8eb6b1523'&gt;Commit 57f2cc</a> on master branch (2.4.5 release)
…

Description

Spring Security does not consider URL path parameters when processing security constraints. By adding a URL path parameter with an encoded "/" to a request, an attacker may be able to bypass a security constraint. The root cause of this issue is a lack of clarity regarding the handling of path parameters in the Servlet Specification (see below). Some Servlet containers include path parameters in the value returned for getPathInfo() and some do not. Spring Security uses the value returned by getPathInfo() as part of the process of mapping requests to security constraints. The unexpected presence of path parameters can cause a constraint to be bypassed.

Users of Apache Tomcat (all current versions) are not affected by this vulnerability since Tomcat follows the guidance previously provided by the Servlet Expert group and strips path parameters from the value returned by getContextPath(), getServletPath() and getPathInfo() [1].

Users of other Servlet containers based on Apache Tomcat may or may not be affected depending on whether or not the handling of path parameters has been modified.

Users of IBM WebSphere Application Server 8.5.x are known to be affected.

Users of other containers that implement the Servlet specification may be affected.

[1] https://issues.apache.org/bugzilla/show_bug.cgi?id=25015

Affected Spring Products and Versions

• Spring Security 3.2.0 - 3.2.9
• Spring Security 4.0.x - 4.1.3
• Spring Security 4.2.0
• Older unsupported versions are also affected

Mitigation

Adopting one of the following mitigations will protect against this vulnerability.

• Use a Servlet container known not to include path parameters in the return values for getServletPath() and getPathInfo()
• Upgrading to Spring Security 3.2.10, 4.1.4 or 4.2.1 will reject the request with a RequestRejectedException if the presence of an encoded "/" is detected. Note: If you wish to disable this feature it can be disabled by setting the DefaultHttpFirewall.allowUrlEncodedSlash = true. However, disabling this feature will mean applications are vulnerable (in containers that return path parameters in getServletPath() or getPathInfo()).

Credit

The issue was identified by Shumpei Asahara & Yuji Ito from NTT DATA Corporation and responsibly reported to Pivotal.

References

• http://www.securityfocus.com/archive/1/archive/1/514517/100/0/threaded
• https://github.com/spring-projects/spring-security/issues/4169
…

Description

Paths provided to the ResourceServlet were not properly sanitized and as a result exposed to directory traversal attacks.

Affected Spring Products and Versions

• Spring Framework 4.3.0 to 4.3.4
• Spring Framework 4.2.0 to 4.2.8
• Spring Framework 3.2.0 to 3.2.17
• Older unsupported versions are also affected

Mitigation

Users of affected versions should apply the following mitigation:

• 4.3.x users should upgrade to 4.3.5
• 4.2.x users should upgrade to 4.2.9
• 3.2.x users should upgrade to 3.2.18

Note that few applications are likely to use the ResourceServlet. It has been generally superseded since version 3.0 (circa 2009) by the ResourceHttpRequestHandler and related classes that have been in use by default and provide much more advanced capabilities, see “Serving Resources” in the reference documentation. The ResourceServlet is now deprecated in 3.2.x and 4.x and is removed altogether starting with version 5.

Credit

The issue was identified by Shumpei Asahara & Yuji Ito from NTT DATA Corporation and responsibly reported to Pivotal.

References

• <a href='https://github.com/spring-projects/spring-framework/commit/e2d6e709c3c65a4951eb096843ee75d5200cfcad'&gt;Commit in 4.3.x branch</a>
• <a href='https://github.com/spring-projects/spring-framework/commit/43bf008fbcd0d7945e2fcd5e30039bc4d74c7a98'&gt;Commit…

Description

Sort instances handed into user defined Spring Data repository query methods using manually declared JPQL queries are handed to the persistence provider as is and allow attackers to inject arbitrary JPQL into ORDER BY clauses which they might use to draw conclusions about non-exposed fields based on the query result's element order changing depending on the injected JPQL.

This especially comes into play if the Sort instances are created from untrustable sources, e.g. web request parameters.

Affected Spring Products and Versions

• Spring Data JPA 1.10.2, 1.9.4
• Other unsupported versions are also affected

Mitigation

Users of affected versions should apply the following mitigation:

• Users are advised to upgrade to Spring Data JPA in version 1.10.4 (Hopper SR4) or 1.9.6 (Gosling SR6). These versions contain sanitizing of the <code>Sort</code> instances handed to the data access layer and only allow referring to domain object fields and aliases used in the JPQL backing the query method.
• Should users still need to hand complex sort expressions to the data access layer, they can use the newly introduced <code>JpaSort.unsafe(…)</code> to reinstantiate the old behavior.

Credit

The vulnerability was reported responsibly by Niklas Särökaari from Silverskin Information Security and Joona Immonen, Arto Santala, Antti Virtanen, Michael Holopainen and Antti Ahola from…

Description

Both Spring Security and the Spring Framework rely on URL pattern mappings for authorization and for mapping requests to controllers respectively.

Differences in the strictness of the pattern matching mechanisms, for example with regards to space…

Description

When processing authorization requests using the whitelabel views, the response_type parameter value was executed as Spring SpEL which enabled a malicious user to trigger remote code execution via the crafting of the value for response_type.

Affected Spring Products and Versions

• 2.0.0 to 2.0.9
• 1.0.0 to 1.0.5

Mitigation

Users of affected versions should apply the following mitigation:

• Users of 1.0.x should not use whitelabel views for approval and error pages
• Users of 2.0.x should either not use whitelabel views for approval and error pages or upgrade to 2.0.10 or later

Credit

This issue was found by David Vieira-Kurz (@secalert) and reported by Oliver Schoenherr on behalf of Immobilien Scout GmbH.

References

• https://github.com/spring-projects/spring-security-oauth/commit/fff77d3fea477b566bcacfbfc95f85821a2bdc2d
…

Description

The class org.springframework.core.serializer.DefaultDeserializer does not validate the deserialized object against a whitelist. By supplying a crafted serialized object like Chris Frohoff's Commons Collection gadget, remote code execution can be achieved.

Affected Spring Products and Versions

• 1.0.0 to 1.5.4

Mitigation

Users of affected versions should apply the following mitigation:

• The cited class (DefaultDeserializer) is not registered by any Spring application context automatically; users should take care when using this class with objects from untrusted sources in the same way they should when using ObjectInputStream directly.
• Spring AMQP has an (optional) message converter that can use this deserializer; starting with version 1.5.5, that converter can now be configured with a whitelist of acceptable packages/classes that can be deserialized.
• Spring AMQP also has a SimpleMessageConverter which *is* configured by default; it doesn't use the deserializer, but does use ObjectInputStream internally; it, too, can now be configured with a whitelist of packages/classes.
• It is recommended that users do not use Java serialization when using RabbitMQ in an environment where untrusted data might be received; if they do, they should configure the converter with the allowable objects.
• Users that might be exposed to this vulnerability should upgrade to Spring AMQP 1.5.5 or higher and configure the whitelist.

Credit

Vulnerability discovery by Matthias Kaiser of Code White (www.code-white.com)

References

• https://jira.spring.io/browse/AMQP-590
• https://github.com/spring-projects/spring-amqp/commit/4150f107e60cac4a7735fcf7cb4c1889a0cbab6c
…

Description

When authorizing an application against an OAuth 2 API provider, Spring Social is vulnerable to a Cross-Site Request Forgery (CSRF) attack. The attack involves a malicious user beginning an OAuth 2 authorization flow using a fake account with an OAuth 2 API provider, but completing it by tricking the victim into visiting the callback request in their browser. As a consequence, the attacker will have access to the victim's account on the vulnerable site by way of the fake provider account.

Affected Spring Products and Versions

• Spring Social Core 1.0.0 to 1.0.3
• Spring Social Core 1.1.0 to 1.1.2

Mitigation

Users of affected Spring Social versions should upgrade as follows:

• For Spring Social 1.0.x upgrade to 1.1.3+
• For Spring Social 1.1.x upgrade to 1.1.3+

In the above mentioned versions, Spring Social requires the existence of a `state` parameter in the callback request. If it is not found, an IllegalStateException is thrown and the authorization flow is terminated.

Credit

The issue was first found by Kris Bosch from Include Security. Paul Ambrosini from sourceclear (https://srcclr.com) then identified the root cause, vulnerable library and vulnerable code.

…

Description

Under some situations, the Spring Framework is vulnerable to a Reflected File Download (RFD) attack. The attack involves a malicious user crafting a URL with a batch script extension that results in the response being downloaded rather than rendered and also includes some input reflected in the response.

For details and concrete examples see the very helpful RFD paper from Trustwave.

Affected Spring Products and Versions

• Spring Framework 3.2.0 to 3.2.14
• Spring Framework 4.0.0 to 4.1.7
• Spring Framework 4.2.0 to 4.2.1
• Other unsupported versions are also affected

Mitigation

Users of affected Spring Framework versions should upgrade as follows:

• For 3.2.x upgrade to 3.2.15+.
• For 4.0.x and 4.1.x upgrade to 4.1.8+.
• For 4.2.x upgrade to 4.2.2+.

In the above mentioned versions Spring MVC checks if the URL contains a file extension prior to writing with an HttpMessageConverter, and if the extension is unknown a “Content-Disposition” response header is added to suggest the download filename “f.txt”. The list of “known” extensions by default includes the ones associated with the built-in HttpMessageConverter implementations as well as any additional extensions explicitly registered for content negotiation purposes. For 4.x the fix also includes URL checks for SockJS URLs and validation of the JSONP callback parameter in all areas where JSONP is supported.

Simply upgrading to the above mentioned versions will protect applications against RFD attacks. Some further steps can be also be taken:

• Encode rather than escape JSON responses. This is also an OWASP XSS recommendation. For an example of how to do that with Spring see https://github.com/rwinch/spring-jackson-owasp.
• Configure suffix pattern matching to be turned off or restricted to explicitly registered suffixes only.
• Configure content negotiation with the properties “useJaf” and “ignoreUknownPathExtension” set to false which would result in a 406 response for URLs with unknown extensions. Note however that this may not be an option if URLs are naturally expected to have a dot towards the end.
• Add 'X-Content-Type-Options: nosniff' header to responses. Spring Security 4 does this by default.

Credit

RFD attacks were described by Trustwave in a paper. The issue in the Spring Framework was responsibly reported to Pivotal by Alvaro Muñoz from HPE Security Research. Special thanks to…