On Thu, Jul 09, 2009 at 09:48:29AM -0400, Dan Poirier wrote: > So if the content-length was parsed correctly, but the vulnerability > related to additional data wasn't fixed, this test would still pass? > (Since then we're not sending any more data than expected?)
That is phrased almost as if there are two separate vulnerabilities here, which is not known to be the case. To ensure there is no misunderstanding here: The root cause of CVE-2009-1890 is that stream_reqbody_cl() would convert the Content-Length from octal rather than decimal for the case of a C-L header with leading zeroes. Fixing that bug fixes the security issue. A second change was also committed, to break out from the loop in the case of a mismatch between length of received data and expected data. That change is a safety and correctness fix; it is not strictly necessary to fix any security vulnerability, so far as I am aware. The test case does not trigger the error path added in the second change, and I know of no way to trigger that error path with the current code. I would certainly not recommend that anybody omit the second change if backporting the fix, however. Hope that is precise enough ;) Regards, Joe