invalid handling of FEXTRA flag within Content-Encoding gzip

RESOLVED DUPLICATE of bug 234031

Status

()

RESOLVED DUPLICATE of bug 234031
3 years ago
3 years ago

People

(Reporter: github, Unassigned)

Tracking

44 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

3 years ago
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;
(Reporter)

Comment 1

3 years ago
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).

Updated

3 years ago
Component: Untriaged → Networking: HTTP
Product: Firefox → Core
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.