This exploit works by making a series of HTTP requests with overlapping ranges in the "Range" or "Request-Range" request headers and results in memory and CPU exhaustion.
For an unpatched Apache server, in many cases a remote unauthenticated attacker could exploit this issue to make the system unresponsive - with only a few packets.
Now, usually this exploit relates to a webserver hosting a website (or multiple websites) so has a limited scope.
However, in the case where the target is the product UI of a Security Gateway, this can mean that the Gateway becomes unresponsive, and if this is a multi-protocol Gateway or Firewall UI - the attacker could potentially disrupt network connectivity (affecting a whole network, rather than a single system).
I have seen several instances recently where a Security Gateway completely freezes up after a few dozen malicious packets, and the system requires a hard-reset (power-cycle) to recover. All network traffic stopped, and the Web UI and even the console were completely unresponsive.
In each of these cases, the Web UIs were often left exposed to the internet (a simple "Google Dork" found dozens of the affected product UIs exposed to the internet).
The solution to this problem is simple, these products need to be patched, but it seems that various vendors of Security Gateways (and other appliances) are not keeping up with their patch-managment, or are unaware of the problem.
This is an example of how to test for this issue (here using Nmap):
(You need the nmap *.nse script from here if you want to test this http://nmap.org/nsedoc/scripts/http-vuln-cve2011-3192.html )
nmap -Pn -sS --script http-vuln-cve2011-3192 -p T:(port here) (ip address here)
Starting Nmap 5.61TEST4 ( http://nmap.org ) at 2012-02-11 20:12 GMT
Nmap scan report for
Host is up (0.22s latency).
PORT STATE SERVICE
| Apache byterange filter DoS
| State: VULNERABLE
| IDs: CVE:CVE-2011-3192 OSVDB:74721
| The Apache web server is vulnerable to a denial of service attack when numerous
| overlapping byte ranges are requested.
| Disclosure date: 2011-08-19
Nmap done: 1 IP address (1 host up) scanned in 3.32 seconds
(It is very important to get the URL to a vulnerable resource correct, otherwise you may miss the issue, GIFs work quite well, but try a few resources)
To be absolutely sure that the vulnerability is exploitable, it can be exploited with Metasploit (make sure you do this in legal and test conditions, such as in a test lab or on a VM you own).
/pentest/exploits/framework/msfcli auxiliary/dos/http/apache_range_dos RLIMIT=50 RHOST=(ip address here)
Here is some detail from Apache on how to address the problem:
...but if you are a customer using one of the affected appliances, you won't be able to fix this yourself, you will need to get in contact with your respective vendor, and get them to "pull their finger out" with their patch-management - and then maybe wait a month or so before they fix it.