Is Tomcat affected by this vulnerability? Here is the advisory announcement.
Essentially, this vulnerability gets the Apache server to build a massive response to a request for a single file, far larger than the file itself. While the RFC (2616) tells web services to accept multiple ranges, there's nothing saying that you can't have the ranges overlap. Bad implementation on Apache's part, but there's a good chance that other web servers are vulnerable.
Most Tomcat servlets don't allow
Current Tomcat code (here) accepts multiple range sets, validates each one individually that it's within the bounds of the file's size, and plops it in a list of ranges to serve. However, the ranges are streamed out in sequence from the servlet's internal cache, and the process should be stopped immediately if the client requesting the data disconnects; in most cases, this should make the overlapping range request roughly equivalent to the performance impact of serving a large file.
And, to confirm, a quick test..
We'll send a quick request against / to get the size..
Verdict is, 1887 bytes for the cute little "It works!" page. That tells us the range we can use without Tomcat throwing away the range as out of bounds.
Ok, so let's check for whether it allows a quick overlap, bytes 0 to 10 then 5 to 15:
Yup, sure enough -
And, whether it'll allow a request for more data than is actually in the file being served:
Yup - nearly 4KB served of a sub-2KB file.
Amplify this approach to include an enormous number of ranges, and this is the basic structure of the attack. In Tomcat's case, the real impact seems to be that it allows an attacker to get a large amount of data served in response to a request for a relatively small resource, which may prove helpful in targeting bandwidth for a denial of service. I'd also be suspicious of the impacts in other edge cases; with a reverse proxy attempting to cache 206 responses, or when the requested resource is a file larger than would fit in the Tomcat cache.
Its not a vulnerability. read the Default servlet code. It loads the resource once. It also reads all the range offsets. Then it iterates through all the offsets serving the content bases on the original resource. Which is DIFFERENT as to how apache httpd did it. So it will not trigger an OOM exception.
You could argue that you could send a LARGE AMOUNT of Range headers to make an exhaustive list or ranges to return. But that is a specific example of a DOS attack on sending too many headers. In which case tomcat and httpd have ways to limit too many request headers as well as their size.
--update Oct 4, 2011--
The only extra resources consumed by such an attack is bandwidth and open socket connections. So it is no different than a standard DOS attack. The only difference is the attacker can be slightly more efficient. But you haven't gained any extra protection by having Tomcat try to perform extra validations on the range.
tl;dr: Probably not.
Given that Apache httpd and Tomcat are different products, and I can't find mention of an equivalent vulnerability announcement in Tomcat, I'd lean towards "no". There's no details in the announcement as to what the exact bug is, so it's hard to say if it's likely that this could be a common programming bug, or something really quite specific to Apache httpd.