Summary

Editor: Spring by Pivotal

Product: Spring Web + Spring Security / Spring Boot

Title: Spring Security / MVC Path Matching Inconsistency

CVE ID: CVE-2016-5007

Intrinsec ID: ISEC-V2016-01

Risk level: Medium to high

Exploitable: remotely

Impact: requests authorization bypass

Description

This vulnerability affects Spring Web and Security when used together if HttpSecurity.authorizeRequests is used for URL access control. Spring provides an example of this in its Spring Security documentation: http://docs.spring.io/spring-security/site/docs/current/reference/html/jc.html#authorize-requests

protected void configure(HttpSecurity http) throws Exception {
	http
		.authorizeRequests()
			.antMatchers("/resources/**", "/signup", "/about").permitAll()
			.antMatchers("/admin/**").hasRole("ADMIN")  
			.antMatchers("/db/**").access("hasRole('ADMIN') and hasRole('DBA')")
			.anyRequest().authenticated()
			.and()
		// ...
		.formLogin();
}

In the following example, the user “user” is not an admin and cannot access “/admin/”:

However, if a space (or another whitespace character) is prepended or appended to “admin” in the URL, the security filter is easily bypassed.

• Space appended (automatically encoded as “%20” by the browser):

• %0D prepended:

The problem is that different matchers are used to implement the access control, and to identify which controller class should handle the request.

The first matcher, used for access control, is strict: “admin “ is considered different than “admin”:

However, the second matcher, used to find the appropriate controller, applies a trim operation which removes whitespaces before and after each URL token, so “admin ” becomes ”admin”:

In conclusion: the access control matcher does not recognize the protected path, thus a default “allow” rule applies, while the controller finder matcher finds the protected controller.

A mismatch of strictness between both matchers is responsible for this condition.

Versions affected

• Spring Security 3.2.x, 4.0.x, 4.1.0
• Spring Framework 3.2.x, 4.0.x, 4.1.x, 4.2.x
• Other unsupported versions are also affected

Solutions

Refer to Pivotal’s CVE-2016-5007 report for detailed mitigations.

Credits

Vulnerability discovered by Clément Notin / @cnotin, in a challenge of the « HackLab ESGI Security Day 2016 » CTF.

Vulnerability disclosed in coordination with the CERT-INTRINSEC.

History

• 2016-03-04: Vulnerability discovery
• 2016-03-07: Advisory writing
• 2016-03-08: Advisory sent to editor
• 2016-03-08: Advisory received and passed to the Spring Security team for evaluation
• 2016-03-15: Status update requested
• 2016-03-17: Status update provided, issue confirmed, project team is assessing options for resolving it
• 2016-04-19: Status update requested
• 2016-04-25: Status update provided, options to resolve it while minimizing the impact on backwards compatibility are still discussed
• 2016-07-07: Vulnerability report and mitigation published by Pivotal

 

— Clément Notin