CVE-2018-1199: Security bypass with static resources

HIGH | JANUARY 29, 2018 | CVE-2018-1199

Description

Spring Security does not consider URL path parameters when processing security constraints. By adding a URL path parameter with special encodings, 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. In this particular attack, different character encodings used in path parameters allows secured Spring MVC static resource URLs to be bypassed.

Affected Spring Products and Versions

  • Spring Security
    • 4.1.0 - 4.1.4
    • 4.2.0 - 4.2.3
    • 5.0.0
  • Spring Framework
    • 5.0.0 - 5.0.2
    • 4.3.0 - 4.3.13
  • Older unmaintained versions of Spring Security & Spring Framework were not analyzed and may be impacted

Mitigation

Users of affected versions should apply the following mitigation:

  • Spring Security<ul><li>5.0.x users should update to 5.0.1</li><li>4.2.x users should update to 4.2.4</li><li>4.1.x users should update to 4.1.5</li></ul>
  • Spring Framework<ul><li>5.0.x users should update to 5.0.3</li><li>4.3.x users should update to 4.3.14</li></ul>

As a general precaution, users are encouraged to separate public and private resources. For example, separating static resources and mapping them to /resources/public/** and /resources/private/** is preferred to having one common root with mixed public and private resource content underneath.

Credit

The issue was identified by Macchinetta Framework Development Team from NTT Comware, NTT DATA Corporation, and NTT, and responsibly reported to Pivotal.

History

2018-01-29: Initial…

CVE-2017-8028: Spring-LDAP authentication with userSearch and STARTTLS allows authentication with arbitrary password

HIGH | OCTOBER 16, 2017 | CVE-2017-8028

Description

When connected to some LDAP servers, when no additional attributes are bound, and when using LDAP BindAuthenticator with org.springframework.ldap.core.support.DefaultTlsDirContextAuthenticationStrategy as the authentication strategy, and setting userSearch, authentication is allowed with an arbitrary password when the username is correct. This occurs because some LDAP vendors require an explicit operation for the LDAP bind to take effect.

Affected Spring Products and Versions

  • Spring-LDAP versions 1.3.0 - 2.3.1

Mitigation

Users of affected versions should apply the following mitigation:

  • Upgrade to Spring-LDAP version 2.3.2.RELEASE+

Credit

This vulnerability was responsibly reported by Tobias Schneider.

References

CVE-2017-8046: RCE in PATCH requests in Spring Data REST

CRITICAL | SEPTEMBER 21, 2017 | CVE-2017-8046

Description

Malicious PATCH requests submitted to servers using Spring Data REST backed HTTP resources can use specially crafted JSON data to run arbitrary Java code.

Affected Spring Products and Versions

  • Spring Data REST versions prior to 2.6.9 (Ingalls SR9), 3.0.1 (Kay SR1)
  • Spring Boot (if Spring Data REST module is used) versions prior to 1.5.9, 2.0 M6

Mitigation

Users of affected versions should apply the following mitigation:

  • Releases that have fixed this issue include:<ul><li>Spring Data REST 2.6.9 (Ingalls SR9, Oct. 27th, 2017)</li><li>Spring Data REST 3.0.1 (Kay SR1, Oct. 27th 2017)</li><li>Spring Boot 1.5.9 (Oct, 28th 2017)</li><li>Spring Boot 2.0 M6 (Nov. 6th 2017)</li></ul>

Credit

This vulnerability was responsibly reported by Man Yue Mo from Semmle and lgtm.com.

References

CVE-2017-8045: Remote code execution in spring-amqp

HIGH | SEPTEMBER 19, 2017 | CVE-2017-8045

Description

In affected versions of Spring AMQP, a org.springframework.amqp.core.Message may be unsafely deserialized when being converted into a string. A malicious payload could be crafted to exploit this and enable a remote code execution attack.

Affected Spring Products and Versions

  • Spring AMQP versions prior to 1.7.4, 1.6.11, and 1.5.7

Mitigation

Users of affected versions should apply the following mitigation:

  • Releases that have fixed this issue include:<ul><li>Spring AMQP: 2.0.0, 1.7.4, 1.6.11, 1.5.7</li></ul>

Credit

This vulnerability was responsibly reported by Man Yue Mo from Semmle and lgtm.com.

References

CVE-2017-8039: Data Binding Expression Vulnerability in Spring Web Flow

MEDIUM | SEPTEMBER 15, 2017 | CVE-2017-8039

Description

This CVE addresses a second path to exploiting the same vulnerability as the one described under CVE-2017-4971.

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.5
  • 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.6

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.

Users of Spring Web Flow with JSF are not impacted by this report.

Credit

The issue was identified by security researcher he1renyagao.

References

CVE-2017-4995: Jackson Configuration Allows Code Execution with Unknown “Serialization Gadgets”

LOW | JUNE 08, 2017 | CVE-2017-4995

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

CVE-2017-4971: Data Binding Expression Vulnerability in Spring Web Flow

MEDIUM | MAY 31, 2017 | CVE-2017-4971

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

CVE-2016-9879 Encoded "/" in path variables

HIGH | DECEMBER 28, 2016 | CVE-2016-9879

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

CVE-2016-9878 Directory Traversal in the Spring Framework ResourceServlet

LOW | DECEMBER 21, 2016 | CVE-2016-9878

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

CVE-2016-6652 Spring Data JPA Blind SQL Injection Vulnerability

MEDIUM | SEPTEMBER 30, 2016 | CVE-2016-6652

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…

Get ahead

VMware offers training and certification to turbo-charge your progress.

Learn more

Get support

Tanzu Spring offers support and binaries for OpenJDK™, Spring, and Apache Tomcat® in one simple subscription.

Learn more

Upcoming events

Check out all the upcoming events in the Spring community.

View all