Tomcat remote denial of service vulnerability analysis(CVE-2 0 1 0-2 2 2 7)-vulnerability warning-the black bar safety net

ID MYHACK58:62201028404
Type myhack58
Reporter 佚名
Modified 2010-11-23T00:00:00


The present article is an analysis of the POC process, the pressure of the N months, and now before the issue. Using the analysis of POC, Tomcat in addition to the latest version(see the specific website), and JBOSS in addition to the latest version, can fight, POC see the article. JBOSS official has secretly released a new version, including bug fixes, but no release announcement.

This vulnerability is really enough cruel! Only need one data packet, directly killed! See Figure, the console information.

Although the official didn't give out the POC, but through simple analysis, we can get out!

(Below is the TOMCAT attack proof) !

Simple analysis:

I see the official patch is such a fight. 5 8 9 7 7&pathrev=9 5 8 9 7 7&diff_format=h


This sentence should read.


pluggableFilterIndex the value of


int type maximum value, and an int will never be greater than int type maximum value, so to say, official patch, never want the program to go into here.

Then look at another file 5 8 9 7 7&pathrev=9 5 8 9 7 7&diff_format=h


if (buffered != null) {


That is, as long as we send a data packet, allowing the program flow normal to go to here. And buffered is null, you can trigger the vulnerability, it just hung up!

To continue the forward analysis with a few debug, it is easy to locate as long as two conditions are met, you can go here:

1, http, head transfer-encoding: buffered

2, using HTTP/1.1 Protocol


So just a tomcat, the non-the latest version of can be, after Contracting(POC), which are head-head:


After my test, swap the two tomcat6. X version, are all directly hang off!

We see the following exception information(This is the JBOSS explosion):


Is org. apache. coyote. http11. filters. BufferedInputFilter the exception.

After I later test found that JBOSS also the existence of this vulnerability, the reason is that JBOSS also uses this package, it is the core of this is the tomcat! Hit a JBOSS, and sometimes also will cause JBOSS to restart, if the first packet is not killed, it is constantly sent dozens of packages, look back, already dead, the effect is very obvious!

The official recommended use:

apache-tomcat-6.0.28 after my test, is not affected.

apache-tomcat-5.5.30 after my test, is not affected.

The official description of the vulnerability mentioned, saying that if the front end using the apache proxy, it will not be a problem, the principle is that apache encounters this header directly is intercepted, then return an error.

But this may not be absolutely safe, if you have apache and tomcat for some character meanings, understanding of the inconsistencies, or the intermediate layer have the character filter mod or the like, may be bypassed. This is purely YY.

I've tested the version:

apache-tomcat-5.5.29 after my test, a dozen hung!

apache-tomcat-6.0.26 after my test, hit the like did not hang, but the message is abnormal, after all the normal access, the message console is the exception, I believe it is also insist on not how long, the rotation playing it will hang.

Tomcat a 6. x and a 5. x version, is also directly linked to, I forget the version number. If your embedded system has installed the tomcat service, you own it.

jboss- a dozen hung, constantly playing, it will restart!

Specific phenomenon:

The first is not accessible, then tomcat does not know from where did you get the file, directly.

Each refresh will change the member content, no matter how the display, not the normal page that should be a buffer hang!

The following figure should be a htm, but I accessed directly, without seeing the source code, that is such a page.


Patch and Description and the solution will not say, see the official announcement.

JBOSS sneak up on the patch version: