Typically web environments allow to configure authentication and access control over a web resource for a list of HTTP methods. For example, a Java Servlet descriptor (web.xml) for a J2EE web application allows to configure security constraints as following :
Here, the web application developer would expect that HTTP GET and POST methods invoked on any web resource (/*) of the application would be subject to authentication constraints as defined and it is also expected that the rest of the HTTP methods would not be allowed to be accessed. In other words, any GET or POST requests without proper authentication to the JBossAdmin realm would be blocked and would get a 401 error.
Vulnerability
The HTTP protocol also supports other methods such as HEAD, PUT, DELETE, etc. Here is the catch. As these methods are not listed in the security constraint shown in above example, the HTTP requests with these methods are still allowed to pass through (by vulnerable web environments) without any authentication or authorization(!). Such requests are typically handled by the default GET handler if no method specific handler is specified. Exactly this vulnerability is exploited by a worm in order to launch a denial of service (DoS) attack. It also seems to have affinity to JBoss's jmx-console :(. It uses HTTP HEAD method on jmx-console to plant seeds of one or more DoS attacks on the infected environment as well as out on the net.
What is (known) to be affected?
According to RedHat/JBoss advisory CVE-2010-0738, this vulnerability is applicable to the following JBoss software.
The advisory says that the default setup of the out of the box web applications such as jmx-console, web-console, etc. of JBoss products listed above enforces incomplete security constraints to ensure authenticated access to the administration user id, defined within these products. A remote attacker, without having access to usernames and passwords, could misuse this setting to trigger arbitrary actions in the context of the operating system user running the Java process and potentially harm confidentiality integrity and availability.
According to Bypassing Web Authentication and Authorization with HTTP Verb Tampering from Aspect Security, this vulnerability might exist in the following since these are known to silently transfer all HTTP HEAD requests to GET handler.
Solution
The best solution for any Java web applications is to either remove all __ from the __ and thus trigger security constraints on all HTTP methods or to list all HTTP methods in the security-constraint as shown in the following example.
Better or
Vulnerability
The HTTP protocol also supports other methods such as HEAD, PUT, DELETE, etc. Here is the catch. As these methods are not listed in the security constraint shown in above example, the HTTP requests with these methods are still allowed to pass through (by vulnerable web environments) without any authentication or authorization(!). Such requests are typically handled by the default GET handler if no method specific handler is specified. Exactly this vulnerability is exploited by a worm in order to launch a denial of service (DoS) attack. It also seems to have affinity to JBoss's jmx-console :(. It uses HTTP HEAD method on jmx-console to plant seeds of one or more DoS attacks on the infected environment as well as out on the net.
What is (known) to be affected?
According to RedHat/JBoss advisory CVE-2010-0738, this vulnerability is applicable to the following JBoss software.
- JBoss Application Server (AS) 4.0.x, 5.1.x
- JBoss Communications Platform 1.2
- JBoss Enterprise Application Platform (EAP) 4.2, 4.3, 5.0
- JBoss Enterprise Portal Platform (EPP) 4.3
- JBoss Enterprise Web Platform (EWP) 5.0
- JBoss SOA-Platform (SOA-P) 4.2, 4.3, 5.0
The advisory says that the default setup of the out of the box web applications such as jmx-console, web-console, etc. of JBoss products listed above enforces incomplete security constraints to ensure authenticated access to the administration user id, defined within these products. A remote attacker, without having access to usernames and passwords, could misuse this setting to trigger arbitrary actions in the context of the operating system user running the Java process and potentially harm confidentiality integrity and availability.
According to Bypassing Web Authentication and Authorization with HTTP Verb Tampering from Aspect Security, this vulnerability might exist in the following since these are known to silently transfer all HTTP HEAD requests to GET handler.
- IIS 6.0
- WebSphere 6.1
- WebLogic 8.2
- JBoss 4.2.2
- Tomcat 6.0
- Apache 2.2.8
Solution
The best solution for any Java web applications is to either remove all _
Better or
No comments:
Post a Comment