User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.82 Safari/537.36 Steps to reproduce: Serve content with Content-Encoding: gzip. The gzip header contains extra data (FEXTRA flag). Actual results: Firefox interprets the correct gzip header wrong, i.e. an XLEN of 5 is interpreted as 0 and an XLEN of 261 as 256 - i.e. only the most significant byte is considered. This is the result of a bug in handling GZIP_EXTRA1 in netwerk/streamconv/converters/nsHTTPCompressConv.cpp, where it simply replaces the value in mLen with the result from the most significant byte of XLEN, i.e. throwing the least significant byte away. Using this misinterpretation data can be constructed where some middlebox (firewall IDS...) sees different data then Firefox and thus a potential attack can be hidden. Expected results: The result from the most significant byte should be added to mLen instead of replacing it: 569 case GZIP_EXTRA1: 570 iStr->Read(&c, 1, &unused); 571 streamLen--; - 572 mLen = ((uInt) c & 0377) << 8; + 572 mLen += ((uInt) c & 0377) << 8; 573 mSkipCount = 0; 574 hMode = GZIP_EXTRA2;
As example one could try http://http-evader.semantic-gap.de/compressed/eicar.txt/ce:gzip;gzip-payload-as-extra Using the current version of Firefox this results in download of the innocent EICAR test virus (see eicar.org). With Chrome you get instead a file with "This is not what you are looking for." inside. The reason is that this short test virus was hidden inside the EXTRA section, but Firefox considered the size of this section (XLEN) as 0 even though it was 70 (0x0046).
this fix for this is in firefox 46.. let me know if you tested with 46 or 47 and didn't see the behavior you expected.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 234031
You need to log in before you can comment on or make changes to this bug.