The issue was confirmed against PHP 5.4.3, but it's very likely that earlier versions can be used too. We are not releasing a proof of concept at this time, but the vulnerability is easy to exploit.
The users of ModSecurity CRS may be protected from this attack, depending on the exact deployment configuration. After the original issue had been reported, a defence-in-depth rule was added to CRS to detect side effects of a bypass attempt. This rule is effective when CRS is deployed in the traditional blocking mode, but not when anomaly scoring mode is used.
This issue should be addressed in ModSecurity's multipart parser. In addition, we recommend the following:
- Short term, improve the recommended default configuration to include the same defense in depth rule as the CRS.
- Long term, implement full request body rewriting. If the multipart payloads are fully rewritten according to how ModSecurity understands them, then any missed attack payloads will not be passed through to the backend. Such approach may require more processing, but we do not believe that this improvement would cause any practical performance issues because multipart content types are infrequent on average.
When the ModSecurity CRS is used to protect certain permissive backend applications, supplying an invalid content type can be used for a complete bypass.
To address unknown content type bypass issues, ModSecurity CRS employs rules that allow only known content types to be used. However, these rules are not strict enough. By default, the CRS will check if the MIME type can be found within the following string (all one continuous line):
application/x-www-form-urlencoded multipart/form-data text/xml application/xml application/x-amf
This check will indeed reject many unknown and invalid MIME types, but it will also accept any substrings that can be found within the above string. In most cases, such invalid MIME types can be used only against a small number of applications. The only situation where this can be exploited is when attacking applications that expect only certain MIME types known to them (e.g., application/x-www-form-urlencoded) and don't check what actual MIME type is indicated in the Content-Type request header.
The attack was confirmed against Apache Commons FileUpload 1.2.1, but earlier versions are equally likely to contribute to the bypass. Starting with the Servlet 3.0 specification, file uploads are supported natively, without the need to use a separate library. The Tomcat web server bundles the FileUpload library to implement file uploads, so even applications that do not explicitly use upload libraries may be vulnerable. The problem likely affects other web servers that are built on the Tomcat code base. Outside Java, at least one other server-side framework is thought to be vulnerable to the same problem.
The attack was confirmed against Apache Commons FileUpload 1.2.1, but earlier versions are equally likely to contribute to the bypass in this way.
The new vulnerabilities discussed here were discovered by Ivan Ristic, from Qualys Vulnerability & Malware Research Labs (VMRL).