Description

Spring Security versions 5.1.x prior to 5.1.2 contain an authorization bypass vulnerability during JWT issuer validation. In order to be impacted, the same private key for an honest issuer and a malicious user must be used when signing JWTs. In that case, a malicious user could fashion signed JWTs with the malicious issuer URL that may be granted for the honest issuer.

Affected Spring Products and Versions

• Spring Framework 5.1 to 5.1.1

Mitigation

Users of affected versions should apply the following mitigation:

• 5.1.x users should upgrade to 5.1.2

There are no other mitigation steps necessary.

Credit

This issue was identified and responsibly reported by Björn Bilger.

References

• Example <a href='https://docs.spring.io/spring-security/site/docs/5.1.1.RELEASE/reference/htmlsingle/#oauth2resourceserver-minimalconfiguration'&gt;config&lt;/a> where a simple Resource Server is enabled.
• <a href='https://docs.spring.io/spring-security/site/docs/5.1.1.RELEASE/reference/htmlsingle/#oauth2resourceserver'&gt;Spring…

Description

Spring Security OAuth, versions 2.3 prior to 2.3.4, and 2.2 prior to 2.2.3, and 2.1 prior to 2.1.3, and 2.0 prior to 2.0.16, and older unsupported versions could be susceptible to a privilege escalation under certain conditions. A malicious user or attacker can craft a request to the approval endpoint that can modify the previously saved authorization request and lead to a privilege escalation on the subsequent approval. This scenario can happen if the application is configured to use a custom approval endpoint that declares AuthorizationRequest as a controller method argument.

This vulnerability exposes applications that meet all of the following requirements:

• Act in the role of an Authorization Server (e.g. @EnableAuthorizationServer)
• Use a custom Approval Endpoint that declares AuthorizationRequest as a controller method argument

This vulnerability does not expose applications that:

• Act in the role of an Authorization Server and use the default Approval Endpoint
• Act in the role of a Resource Server only (e.g. @EnableResourceServer)
• Act in the role of a Client only (e.g. @EnableOAuthClient)

Affected Spring Products and Versions

• Spring Security OAuth 2.3 to 2.3.3
• Spring Security OAuth 2.2 to 2.2.2
• Spring Security OAuth 2.1 to 2.1.2
• Spring Security OAuth 2.0 to 2.0.15
• Older unsupported versions are also affected

Mitigation

Users of affected versions should apply the following mitigation:

• 2.3.x users should upgrade to 2.3.4
• 2.2.x users should upgrade to 2.2.3
• 2.1.x users should upgrade to 2.1.3
• 2.0.x users should upgrade to 2.0.16
• Older versions should upgrade to a supported branch

There are no other mitigation steps required.

Credit

This issue was identified and responsibly reported by Alvaro Muñoz (@pwntester) from Micro Focus.

References

• Spring Security OAuth <a href="http://projects.spring.io/spring-security-oauth/docs/oauth2.html"&gt;documentation&lt;/a&gt;, see section "Authorization Server Configuration"
• Example configuration for <a href="https://github.com/spring-projects/spring-security-oauth/blob/master/tests/annotation/approval/src/main/java/demo/Application.java#L36"&gt;&lt;code&gt;@EnableAuthorizationServer&lt;/code&gt;&lt;/a…

Description

Spring Framework, version 5.1, versions 5.0.x prior to 5.0.10, versions 4.3.x prior to 4.3.20, and older unsupported versions on the 4.2.x branch provide support for range requests when serving static resources through the ResourceHttpRequestHandler, or starting in 5.0 when an annotated controller returns an org.springframework.core.io.Resource. A malicious user (or attacker) can add a range header with a high number of ranges, or with wide ranges that overlap, or both, for a denial of service attack.

This vulnerability affects applications that depend on either spring-webmvc or spring-webflux. Such applications must also have a registration for serving static resources (e.g. JS, CSS, images, and others), or have an annotated controller that returns an org.springframework.core.io.Resource.

Spring Boot applications that depend on spring-boot-starter-web or spring-boot-starter-webflux are ready to serve static resources out of the box and are therefore vulnerable.

Affected Spring Products and Versions

• Spring Framework 5.1
• Spring Framework 5.0.0 to 5.0.9
• Spring Framework 4.3 to 4.3.19
• Older unsupported versions going back to 4.2 are also affected

Mitigation

Users of affected versions should apply the following mitigation:

• 5.1 users should upgrade to 5.1.1
• 5.0.x users should upgrade to 5.0.10
• 4.3.x users should upgrade to 4.3.20
• 4.2.x users should upgrade to a supported branch.

No further mitigation steps are necessary.

Note the following when evaluating the impact:

• Support for Range requests was introduced in version 4.2. Therefore versions prior to 4.2 are not affected by this issue.
• Support for returning an org.springfamework.core.io.Resource from an annotated controller was introduced in 5.0. Therefore versions prior to 5.0 can only be impacted through a registration to serve static resources.

Credit

This issue was identified and responsibly reported by Nicholas Starke from Aruba Threat Labs.

History

2018-10-16: Initial vulnerability report published.

Description

spring-amqp, 1.x versions prior to 1.7.10, 2.x versions prior to 2.0.6 expose a man-in-the middle vulnerability.

The Spring RabbitMQ Java Client does not perform hostname validation.

This means that SSL certificates of other hosts are blindly accepted as long as they are trusted.

To exploit this vulnerability an attacker has to perform a man-in-the-middle (MITM) attack between a Java application using the Spring RabbitMQ Java Client and an RabbitMQ server it's connecting to.

TLS normally protects users and systems against MITM attacks, it cannot if certificates from other trusted hosts are accepted by the client.

Spring AMQP uses the RabbitMQ amqp-client java library for communication with RabbitMQ.

It uses the RabbitConnectionFactoryBean to create/configure the connection factory.

Affected Spring Products and Versions

• Spring-AMQP versions prior to 1.7.10 and 2.0.6
• RabbitMQ amqp-client versions prior to 4.8.0 and 5.4.0

Mitigation

Users of affected versions should apply the following mitigation:

• Upgrade to the 1.7.10.RELEASE or 2.0.6.RELEASE and set the enableHostnameValidation property to true. Override the transitive amqp-client version to at least 4.8.0 and 5.4.0, respectively
• The upcoming 2.1.0.RELEASE will set the property to true by default.
• If you are using the amqp-client library directly to create a connection factory, refer to its javadocs for the enableHostnameValidation() method.

Credit

This issue was identified and responsibly reported by Peter Stöckli of Alphabot Security, Switzerland.

History

2018-09-11: Initial vulnerability report published.

Description

Spring Framework (versions 5.0.x prior to 5.0.7, versions 4.3.x prior to 4.3.18, and older unsupported versions) allow web applications to change the HTTP request method to any HTTP method (including TRACE) using the HiddenHttpMethodFilter in Spring MVC. If an application has a pre-existing XSS vulnerability, a malicious user (or attacker) can use this filter to escalate to an XST (Cross Site Tracing) attack.

Affected Spring Products and Versions

• Spring Framework 5.0 to 5.0.6
• Spring Framework 4.3 to 4.3.17
• Older unsupported versions are also affected

Mitigation

Users of affected versions should apply the following mitigation:

• 5.0.x users should upgrade to 5.0.7
• 4.3.x users should upgrade to 4.3.18
• Older versions should upgrade to a supported branch

There are no other mitigation steps necessary.

This attack applies to applications that:

• Use the HiddenHttpMethodFilter (it is enabled by default in Spring Boot)
• Allow HTTP TRACE requests to be handled by the application server

This attack is not exploitable directly because an attacker would have to make a cross-domain request via HTTP POST, which is forbidden by the Same Origin Policy. This is why a pre-existing XSS (Cross Site Scripting) vulnerability in the web application itself is necessary to enable an escalation to XST.

Credit

This issue was identified and reported by Mariusz Łuciów, Ocado Technology.

History

2018-06-14: Initial vulnerability report published.

Description

Spring Framework, versions 5.0.x prior to 5.0.7, versions 4.3.x prior to 4.3.18, and older unsupported versions, allows web applications to enable cross-domain requests via JSONP (JSON with Padding) through AbstractJsonpResponseBodyAdvice for REST controllers, and MappingJackson2JsonView for browser requests. Both are not enabled by default in Spring Framework nor Spring Boot. However when MappingJackson2JsonView is configured in an application, JSONP support is automatically ready to use through the "jsonp" and "callback" JSONP parameters, enabling cross-domain requests.

Allowing cross-domain requests from untrusted origins may expose user information to 3rd party browser scripts.

This vulnerability applies to applications that:

• Explicitly configure MappingJackson2JsonView.
• And do not set the jsonpParameterNames property of MappingJackson2JsonView to an empty set.
• And expose sensitive user information over endpoints that can render content with JSONP.

Affected Spring Products and Versions

• Spring Framework 5.0 to 5.0.6
• Spring Framework 4.1 to 4.3.17

Mitigation

Users of affected versions should apply the following mitigation:

• 5.0.x users should upgrade to 5.0.7.
• 4.3.x users should upgrade to 4.3.18.
• Older versions should upgrade to a supported branch, or otherwise set MappingJacksonJsonView’s jsonpParameterNames property to an empty set.

Applications that do require JSONP support will need to explicitly configure the jsonpParameterNames property of MappingJacksonJsonView following the upgrade. It is recommended that applications switch to using CORS instead of JSONP to enable cross-domain requests. JSONP support in the Spring Framework is deprecated as of 5.0.7 and 4.3.18 and will be removed in 5.1.

Credit

This issue was identified and reported by Meyyalagan Chandrasekaran.

References

• <a href='https://jira.spring.io/browse/SPR-16798'&gt;SPR-16798&lt;/a> “Deprecate JSONP support and update MappingJackson2JsonView”
• <a href='https://docs.spring.io/spring/docs/current/spring-framework-reference/web.html#mvc-config-view-resolvers'&gt;Example…

Description

spring-integration-zip , versions prior to 1.0.2, exposes an arbitrary file write vulnerability, that can be achieved using a specially crafted zip archive (affects other archives as well, bzip2, tar, xz, war, cpio, 7z), that holds path traversal filenames. So when the filename gets concatenated to the target extraction directory, the final path ends up outside of the target folder. The previous CVE-2018-1261 prevented the framework itself from writing the file. While the framework itself now does not write such files, it does present the errant path to the user application, which could inadvertently write the file using that path.

This specifically applies to the unzip transformer.

This can only happen if an application using this library accepts and unpacks zip files from untrusted sources.

Affected Spring Products and Versions

• Spring Integration Zip Community Extension Project versions 1.0.1.RELEASE and earlier.

Mitigation

Users of affected versions should apply the following mitigation:

• Upgrade to the 1.0.2.RELEASE

Or do not unzip untrusted zip files.

Credit

This issue was identified and responsibly reported by the Snyk Security Research Team and Abago Forgans.

History

2018-05-11: Initial vulnerability report published

Description

Spring Security in combination with Spring Framework 5.0.5.RELEASE contain an authorization bypass when using method security. An unauthorized malicious user can gain unauthorized access to methods that should be restricted.

Affected Spring Products and Versions

• Spring Framework 5.0.5.RELEASE and Spring Security (any version)
• Applications are only impacted if they use Spring Framework 5.0.5.RELEASE and Spring Security method security. The bug is present in Spring Framework 5.0.5.RELEASE, but is not considered a CVE unless combined with Spring Security’s method security support.
• The bug is present only in Spring Framework 5.0.5.RELEASE. If the application does not use Spring Framework 5.0.5.RELEASE then it is not impacted. The bug does not impact any Spring Framework 4.x versions or any other versions of Spring Framework.

Mitigation

• Users leveraging Spring Framework 5.x should avoid using Spring Framework 5.0.5.RELEASE. Updating to Spring Security 5.0.5.RELEASE+ or Spring Boot 2.0.2.RELEASE+ brings in Spring Framework 5.0.6.RELEASE+ transitively. However, users should be certain that other dependency management mechanisms are also updated to use Spring Framework 5.0.6.RELEASE or newer.
• Users leveraging Spring Framework 4.x (Spring Security 4.x or Spring Boot 1.x) are not impacted so no steps are necessary.
• There are no other mitigation steps required.

Credit

This issue was identified internally by the Spring Security Team.

History

2018-05-09: Initial vulnerability report published

• 2018-07-30: Clarifications on impacted versions

Description

Spring Framework, versions 5.0.x prior to 5.0.6 and versions 4.3.x prior to 4.3.17, and older unsupported versions allow applications to expose STOMP over WebSocket endpoints with a simple, in-memory STOMP broker through the spring-messaging module. A malicious user (or attacker) can craft a message to the broker that can lead to a regular expression, denial of service attack.

This vulnerability exposes applications that meet all of the following requirements:

• Depend on spring-messaging and spring-websocket modules.
• Register STOMP over WebSocket endpoints.
• Enable the simple STOMP broker.

Affected Spring Products and Versions

• Spring Framework 5.0 to 5.0.5
• Spring Framework 4.3 to 4.3.16
• Older unsupported versions are also affected

Mitigation

Users of affected versions should apply the following mitigation:

• 5.0.x users should upgrade to 5.0.6.
• 4.3.x users should upgrade to 4.3.17.
• Older versions should upgrade to a supported branch.

There are no other mitigation steps necessary.

Note that the use of authentication and authorization for messages, both of which are provided by Spring Security, limits exposure to this vulnerability to authorized users.

Credit

This issue was identified and responsibly reported by Muneaki Nishimura (nishimunea) of Recruit Technologies Co., Ltd.

References

• Example <a href='https://docs.spring.io/spring/docs/current/spring-framework-reference/web.html#websocket-stomp-enable'&gt;STOMP over WebSocket config</a> where simple broker is enabled.
• <a href='https://docs.spring.io/spring-security/site/docs/5.0.3.RELEASE/reference/htmlsingle/#websocket'&gt;Spring…

Description

Spring Data Commons, versions prior to 1.13 to 1.13.11 and 2.0 to 2.0.6 used in combination with XMLBeam 1.4.14 or earlier versions contain a property binder vulnerability caused by improper restriction of XML external entity references as underlying library XMLBeam does not restrict external reference expansion. An unauthenticated remote malicious user can supply specially crafted request parameters against Spring Data’s projection-based request payload binding to access arbitrary files on the system.

Affected Spring Products and Versions

• Spring Data Commons 1.13 to 1.13.11 (Ingalls SR11)
• Spring Data REST 2.6 to 2.6.11 (Ingalls SR11)
• Spring Data Commons 2.0 to 2.0.6 (Kay SR6)
• Spring Data REST 3.0 to 3.0.6 (Kay SR6)

Mitigation

Users of affected versions should apply the following mitigation:

• 1.13.x users should upgrade to 1.13.12 (Ingalls SR12)
• 2.0.x users should upgrade to 2.0.7 (Kay SR7)
• Alternatively, upgrade to XMLBeam 1.4.15

Releases that have fixed this issue include:

• Spring Data REST 2.6.12 (Ingalls SR12)
• Spring Data REST 3.0.7 (Kay SR7)

There are no other mitigation steps necessary.

Note that the vulnerability is only exploitable when using XMLBeam. The use of authentication and authorization for endpoints, both of which are provided by Spring Security, limits exposure to this vulnerability to authorized users.

Credit

This issue was identified and responsibly reported by Abago Forgans.

References

• <a href='https://jira.spring.io/browse/DATACMNS-1292'&gt;https://jira.spring.io/browse/DATACMNS-1292&lt;/a>
• <a href='https://docs.spring.io/spring-data/commons/docs/current/reference/html/#core.web.binding'&gt;Spring Data Commons: Web databinding support</a>
…