yos20053@xxxxxxxxx wrote:
Dear Bill From Apache I think that you didn't understand this vulnerability properly.
We understand it quite well; we simply disagree on the context of which is vulnerable, the Apache server which holds to RFC2616, or IE (and Firefox apparently in some cases) which do not. Even allowing for the flexibility of toggling between ISO, UTF-8 and other 7bit ascii-clean character sets, the choice by IE and Firefox to violate the RFC in this manner accepting by guesswork UTF-7 with no canonical definition of the basic HTML control set clearly has broader implications. I trust as a researcher you can fill your days for a good long time finding similarly vulnerable configurations and applications, when in fact the origin of this problem lies in the client.
We know how to solve this problem and if you want we can help you...
As do we; I mentioned in my first reply that the workaround is in place for a host of Apache-generated responses, including 403 errors, as of the current releases of the code (2.2.8, 2.0.63 and 1.3.41). But again this is working around the client's flaw, not a vulnerability fix of Apache's flaw, which is why the security team deliberately did not allocate a CVE at the time these changes were applied. [Some related XSS flaws which did not rely on client misbehavior were tagged as vulnerabilities.] For future reference, you are certainly welcome at security@xxxxxxxxxx to sanity check future vulnerability reports before publication, we are always happy to help out researchers. And we are also very happy to coordinate security patch releases with scheduled publication of vulnerabilities for those who prefer this method, although we talk equally with full-disclosure folk as well. Bill
