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.
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…
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.
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)
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.
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:
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…
XML external entities were previously disabled with the publication of http://pivotal.io/security/cve-2013-6429. If DTD is not entirely disabled, inline DTD declarations can be used to perform Denial of Service attacks known as XML bombs. Such declarations are both well-formed and valid according to XML schema rules but when parsed can cause out of memory errors. To protect against this kind of attack DTD support must be disabled by setting the disallow-doctype-dec feature in the DOM and SAX APIs to true and by setting the supportDTD property in the StAX API to false.
This is now done in the Spring Framework by default wherever the framework sets up XML parsing from external sources. Mainly this includes the Unmarshaller implementations in spring-oxm and the HttpMessageConverter implementations in spring-web.
Note that further actions may need to be taken by applications in particular where use of StAX is concerned. For example IBM JDK 1.6 and 1.7 require an environment variable in addition to setting supportDTD=false (see IBM JDK reference). Moreover we’ve found that supportDTD alone does not protect against all kinds of DoS attacks with JDK JAXP implementations. Hence we recommend using the Woodstox open source library for StAX parsing.
The following describes when StAX is used in the Spring Framework:
SourceHttpMessageConverter -- enabled by default. The converter was added in 3.2 while StAX support was added in 4.0.1 and is used when converting to Spring MVC controller method argument of type javax.xml.transform.stax.StAXSource.
Jaxb2CollectionHttpMessageConverter -- not enabled by default. This converter was added in 3.2.
MappingJackson2XmlHttpMessageConverter -- enabled when “jackson-dataformat-xml” is present on the classpath. This converter was added in 4.1.
Affected Spring Products and Versions
Spring Framework 3.2.0 to 3.2.13
Spring Framework 4.0.0 to 4.1.6
Other unsupported versions are also affected
Mitigation
Users of affected Spring Framework versions should upgrade as follows:
For 3.2.x upgrade to <strong>3.2.14+</strong>
For 4.0.x and 4.1.x upgrade to <strong>4.1.7+</strong>
In addition, applications that consume XML input via StAX from external sources should also use and/or upgrade to a recent version of the Woodstox library, e.g. version 4.2+ (4.2.1 is the currently curated version in the Spring IO Platform).
Notes on adding Woodstox:
StAX defines a standard mechanism for selecting which StAX implementation to use when more than one is available including system properties and service definitions under WEB-INF/services. Woodstox includes the necessary service definitions so that simply adding it to the classpath should work. However some application servers such as WebLogic already bundle (an older version) of Woodstox in which case you may need to configure the server to prefer the one chosen by the application, see this reference on prefer-application-packages.
Credit
This issue was identified responsibly and reported to Pivotal by Toshiaki Maki of NTT DATA Corporation who also helped to develop and test the solution.
Session id generation in the Java SockJS client is not sufficiently secure and could allow a user to send messages to another user’s session.
Note that this only affects users of the Java SockJS client, which generates its own session id. It does not affect browser clients even if they’re connecting to the same server.
Furthermore, since SockJS is a transport layer, when using a higher level messaging protocol on top such as STOMP over WebSocket with the spring-messaging module, application-level security may already be getting applied to STOMP messages and that can neutralize the impact of any potential attacks.
Affected Spring Products and Versions
Spring Framework 4.1.0 to 4.1.4
Mitigation
Users of affected versions should apply the following mitigation:
Users of 4.1.x should upgrade to 4.1.5 or later
Credit
Philippe Arteau found and responsibly reported the problem to Pivotal.
Some URLs were not santized correctly before use allowing an attacker to obtain any file on the file system that was also accessible to process in which the Spring web application was running.
Affected Spring Products and Versions
Spring Framework 3.0.4 to 3.2.11
Spring Framework 4.0.0 to 4.0.7
Spring Framework 4.1.0 to 4.1.1
Other unsupported versions may also be affected
Mitigation
Users of affected versions should apply the following mitigation:
Users of 3.2.x should upgrade to 3.2.12 or later
Users of 4.0.x should upgrade to 4.0.8 or later
Users of 4.1.x should upgrade to 4.1.2 or later
Credit
This issue was identified by Toshiaki Maki of NTT DATA Corporation and responsibly reported to Pivotal.
