IPS false positive HTTP.Chunk.Overflow

There are three related signatures which deal with chunk overflow vulnerabilities on client and server machines: HTTP.Chunk.Overflow, Oracledb.Apache.Chunked.Encoding.Overflow, and MS.Windows.HTTP.Services.Integer.Underflow. The latter two are only part of the IPS extended database. I think the fact that the two other signatures are only available in the extended database is telling for whether these events are a false positive or not. The FortiGuard encyclopedia article on the HTTP.Chunk.Overflow signature mentions that, aside from Apache, the exploit can also target older versions of Windows NT (Windows 2000, Server, Vista, etc.) as a client OS, not just an Apache server. However, given the age of the OS group mentioned, I don' t think the chunk overflow is a client threat any longer. I highly doubt that Google would be running an unpatched version of Apache on their servers. Combine that with the fact that the log entry for the event *usually* notes the direction of the detected event was *inbound* towards the client, and this is what I think is most likely: -The events are a false positive - your hosts are not at risk -It likely has to do with how Google sends data to clients In fact, there have been a number of similar cases recently. Tickets mentioning a chunk overflow date back to at least 2010, but Google is mentioned by name frequently in the past few weeks. I suspect they may have changed their server behavior, but not for all content, and possibly only for certain client operating systems connecting. According to another ticket I found last week, the IPS engine employs a chunk parser to check for chunk or heap overflows, simply by verifying whether or not they meet the criteria laid out in RFC 2616: Chunked-Body = *chunk last-chunk trailer CRLF chunk = chunk-size [ chunk-extension ] CRLF chunk-data CRLF chunk-size = 1*HEX last-chunk = 1*(" 0" ) [ chunk-extension ] CRLF chunk-extension= *( " ;" chunk-ext-name [ " =" chunk-ext-val ] ) chunk-ext-name = token chunk-ext-val = token | quoted-string chunk-data = chunk-size(OCTET) trailer = *(entity-header CRLF) (https://www.ietf.org/rfc/rfc2616.txt) The test for this specific attack appears to be rather simple, which is why the other two signatures are needed in tandem to verify whether the packet actually represents a crafted attack - what we internally labelled a " specific evil size/data payload" . I highly doubt you need to worry about that signature, so if you don' t mind it, you can create a new rule above the others in an IPS sensor with only the one signature, HTTP.Chunk.Overflow, and set the override action to monitor. If you want to prevent any possible exploit on client machines in the future, below this top rule, you could add the two other signatures with a block or reset action, as long as you have loaded the extended IPS DB. That will likely completely do away with the alerts you have been seeing. Otherwise, if you volunteer to, you could take a packet capture of an example of a false positive for HTTP.Chunk.Overflow, and provide it to our IPS team to help re-define the signature. Past cases either didn' t capture the right traffic, or were closed before a resolution (the ticket creator didn' t mind the alerts anymore, or was fine with simply passing the traffic through).