[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Full-disclosure] CVE-2010-3700: Spring Security bypass of security constraints



CVE-2010-3700 - Spring Security - Bypassing of security constraints


Severity:
Important


Vendor:
SpringSource, a division of VMware


Versions affected:
Spring Security 3.0.0 to 3.0.3
Spring Security 2.0.0 t0 2.0.5
Acegi Security 1.0.0 to 1.0.7


Description:
Spring Security does not consider URL path parameters when processing security 
constraints. By adding an URL path parameter 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().

Users of SpringSource tc Server (all versions) are not affected. tc Server uses 
Apache Tomcat and does not change the handling of path parameters.

Users of SpringSource dm Server (all versions) are not affected. dm Server uses 
Apache Tomcat and does not change the handling of path parameters.

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 Geronimo 2.2 with Jetty 7 are not affected.

Users of IBM WebSphere Application Server 6.1 and 7.0 are known to be affected.

Users of other containers that implement the Servlet specification may be 
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()
- upgrade to Spring Security 2.0.6 or Spring Security 3.0.4


Example:
An application that uses the following intercept URL pattern:
<intercept-url pattern="/*-add.do" access="PERMISSION_ADMIN"/>
to protect URLs such as:
/myapp/account-add.do
can be exploited by an attacker that uses a URL of the form:
/ctx/account-add.do;x=-pub.do


Credit:
This issue was discovered and reported to the SpringSource security team
by Ed Schaller.


Path parameters and the Servlet Specification:
This discussion applies to versions 2.3, 2.4, 2.5 & 3.0 of the Servlet 
Specification.

The Servlet Specification defines the following:
requestURI = contextPath + servletPath + pathInfo

It also states that:
- path parameters are returned by getRequestURI() and getPathInfo()
- context path & path parameters are ignored when mapping requests to servlets 
(2.4 onwards)

The specification does not state:
- if the value returned by getContextPath() include path parameters or not. The 
implication is that it should not.
- if the value returned by getServletPath() include path parameters or not. The 
implication is that it should not.

The Servlet expert group has previously indicated [1] that the specification 
would be altered to state that getPathInfo() should not return path parameters 
and that clarification would be added to confirm that getContextPath() and 
getServletPath() should not return path parameters either. This clarification 
was never added to the specification.


References:
[1] https://issues.apache.org/bugzilla/show_bug.cgi?id=25015
[2] http://www.springsource.com/security/spring-security
[3] http://www.springsource.com/download/community?project=Spring%20Security
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/