Wrong vulnerability search string.
joakime opened this issue · 5 comments
The search string of "400 Illegal character 0x0 in state" is really the wrong way to look for this vulnerability.
It should verify that the response is of error code 400, then look for either "<<<" or ">>>" in the response status line. If either of those 2 strings exist, then you have a vulnerable system.
Is the current method prone to false positives or negatives, or is this just a style thing? I ripped the technique from https://github.com/GDSSecurity/Jetleak-Testing-Script
(ie how quickly do I need to fix this)
The string 400 Illegal character 0x0 in state doesn't mean the flaw is there.
The flaw, the actual vulnerability, is the part where the extra buffer is returned.
Documented in a bit more detail (from Jetty's point of view) here
https://github.com/eclipse/jetty.project/blob/master/advisories/2015-02-24-httpparser-error-buffer-bleed.md
The important part is the buffer that is revealed, check for that.
That can easily be checked for using one of those 2 strings "<<<" or ">>>"
Jetty 9.2.9 (with fix) currently returns 400 Illegal character 0x[0-9A-F]*, but if we add back the state reference to include WHERE in the header the fault resided then it would be 400 Illegal character 0x[0-9A-F]* in state [A-Z_]*, which means your scan and script now triggered on a valid version of Jetty as having a fault. Even though no such thing actually occurred.
Filed the issue with GDS Security too.
Thanks for clarifying, will fix.