Content injection spoofing with a combination of headers defined by HTTP/1.0 and 1.1 (e.g. Content-Length and Transfer-Encoding: chunked)

RESOLVED FIXED in mozilla1.8.1

Status

()

Core
Networking: HTTP
P1
critical
RESOLVED FIXED
12 years ago
9 years ago

People

(Reporter: kohei, Assigned: Darin Fisher)

Tracking

({fixed1.8.1, testcase, verified1.8.0.4})

Trunk
mozilla1.8.1
fixed1.8.1, testcase, verified1.8.0.4
Points:
---
Bug Flags:
blocking1.8.1 +
blocking1.8.0.4 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:high])

Attachments

(4 attachments)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Build Identifier: N/A

Note: This bug was originally reported to IPA (Information-technology Promotion Agency, Japan) and forwarded to us at Mozilla Japan. I'm NOT original reporter. Don't mention my name in the security advisory. For more information about IPA, visit http://www.ipa.go.jp/about/english/ 

JVN28513736

Attackers can forge a Web page on another domain by sending the HTTP response including "Content-Length" header and "Transfer-Encoding: chunked" header. This could be used for the real phishing to steal sensitive data, such as user password or cookies. 

Windows XP Professional SP2
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060129 Firefox/1.6a1


Reproducible: Sometimes

Steps to Reproduce:
1. Set up Firefox to use Squid/2.5.STABLE12 for HTTP proxy
2. Configure Squid. Set the value of "persistent_request_timeout" to "1 minute".
2. Provide the proxy with HTTP response with the following conditions:
 A. "Content-Length" header is included
 B. "Transfer-Encoding: chunked" is included
 C. response length with chunk size data of B is shorter than the value of A

Actual Results:  
Squid conforms to HTTP/1.0, not to HTTP/1.1. Therefore, It will send data of the number of bytes specified by Content-Length header to the browser. Transfer-Encoding header with a space will be transferred as is. This is appropriate behavior compliant with HTTP/1.0.

Firefox will receive the response via proxy and handle the response body based on Transfer-Encoding header. Firefox determines the termination of message body based on the last chunk of chunked encoding, not Content-Length.

The rest of response determined by the condition C is incorrectly recognized as the response of following HTTP request.


Expected Results:  
The rest of response should not be recognized as the response of following HTTP request.


Additional Information:
The malicious Web site admins can target Firefox users who use HTTP proxy (that keep-alive anabled) to steal cookies or build web pages including fake login form for arbitrary domains.

Original reporter says that Firefox doesn't ignore the header that isn't part of HTTP/1.0 (but is defined by HTTP/1.1) when it interprets HTTP/1.0 response. Although this report makes an issue of Transfer-Encoding header, but other headers might be a problem.

Reporter also says Firefox should be implemented not to reuse stream that is connected to the HTTP proxy when it starts connection to another web server.

Workaround for Squid admins: disable keep-alive
(Reporter)

Comment 1

12 years ago
Created attachment 214812 [details]
data flow chart

IPA send us the data flow chart. I attach it.
(Reporter)

Updated

12 years ago
Summary: Content injection spoofing with a combination of headers defined by HTTP/1.0 and HTTP/1.1 (e.g. Content-Length and Transfer-Encoding) → Content injection spoofing with a combination of headers defined by HTTP/1.0 and 1.1 (e.g. Content-Length and Transfer-Encoding: chunked)
Assignee: nobody → darin
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 2

11 years ago
Any updates?
Flags: blocking1.9a1?
Flags: blocking1.8.1?
Flags: blocking1.8.0.3?
(Assignee)

Updated

11 years ago
Target Milestone: --- → mozilla1.8.1
(Assignee)

Comment 3

11 years ago
So, I think that if we get a HTTP/1.0 response, we should favor a Content-Length header of a Transfer-Encoding header.  I worry that ignoring Transfer-Encoding headers entirely will result in incompatibilities.  I need to check what IE does.
(Assignee)

Updated

11 years ago
Status: NEW → ASSIGNED
Priority: -- → P1
Flags: blocking1.8.1?
Flags: blocking1.8.1+
Flags: blocking1.8.0.3?
Flags: blocking1.8.0.3+
Whiteboard: [sg:high]
(Assignee)

Comment 4

11 years ago
IE6 seems to correctly ignore the "Transfer-Encoding: chunked" header when included in the response from a HTTP/1.0 server.  So, we can easily do the same.
(Assignee)

Comment 5

11 years ago
Created attachment 217164 [details]
testcase: python script

Here's a simple python script that demonstrates the bug.  Load http://host:4444/ twice and if you get a popup that says "hacked" then you're browser is vulnerable.
(Assignee)

Comment 6

11 years ago
Created attachment 217165 [details] [diff] [review]
v1 patch

Make us behave like IE6.
Attachment #217165 - Flags: superreview?(bzbarsky)
Attachment #217165 - Flags: review?(cbiesinger)
Attachment #217165 - Flags: superreview?(bzbarsky) → superreview+
Attachment #217165 - Flags: review?(cbiesinger) → review+
but what does IE6 do when the version is 1.1 and the situation is otherwise the same? put differently, doesn't this just require changing the attack to use a 1.1 version?
(Assignee)

Comment 8

11 years ago
> but what does IE6 do when the version is 1.1 and the situation is otherwise the
> same? put differently, doesn't this just require changing the attack to use a
> 1.1 version?

You're asking what if the proxy server spoke 1.1?  Then, the proxy server would not be fooled into forwarding the embedded response, and the exploit wouldn't exist.  My python testcase is not an exact replica of the actual exploit in that it is not a proxy server.  It just demonstrates the same underlying problem.
(Assignee)

Comment 9

11 years ago
fixed-on-trunk
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
(Assignee)

Updated

11 years ago
Attachment #217165 - Flags: approval1.8.0.3?
Attachment #217165 - Flags: approval-branch-1.8.1?(bzbarsky)
Attachment #217165 - Flags: approval-branch-1.8.1?(bzbarsky) → approval-branch-1.8.1+

Comment 10

11 years ago
Comment on attachment 217165 [details] [diff] [review]
v1 patch

a=jay for drivers, please get this on the 1.8.0 branch.  Thanks!
Attachment #217165 - Flags: approval1.8.0.3? → approval1.8.0.3+
(Assignee)

Comment 11

11 years ago
fixed1.8.1
Keywords: fixed1.8.1
(Assignee)

Comment 12

11 years ago
fixed1.8.0.3
Keywords: fixed1.8.0.3

Comment 13

11 years ago
v.fixed on 1.8.0 branch: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.8.0.2) Gecko/20060420 Firefox/1.5.0.2, no "hacked" popup with Darin's python script testcase.

Kohei:  If you want to also verify this bug and the other http header fixes with your proxy setup, please do so and let us know if things look ok.  Thanks!
Keywords: fixed1.8.0.3 → testcase, verified1.8.0.3
Whiteboard: [sg:high] → [sg:high] coordinate advisory release with IPA
(Reporter)

Comment 14

11 years ago
IPA have confirmed that this vulnerability affects Firefox only.
It's OK to publish security advisory as of Firefox 1.5.0.4. Thanks!
Whiteboard: [sg:high] coordinate advisory release with IPA → [sg:high]
(Reporter)

Comment 15

11 years ago
IPA told us that the original reporter is Kazuho Oku (Cybozu Labs).
FYI: http://labs.cybozu.co.jp/en/archives/2005-08-16-1.html

dveditz: Please mention his name in the upcoming advisory.
Flags: blocking1.7.14?
Flags: blocking-aviary1.0.9?
Group: security

Comment 16

11 years ago
Created attachment 225475 [details] [diff] [review]
1.0.x version

a proposed backport.

Updated

11 years ago
Attachment #225475 - Flags: review?(caillon)

Updated

10 years ago
Flags: blocking1.9a1?
Flags: blocking1.7.14?
Flags: blocking-aviary1.0.9?
Depends on: 429629
You need to log in before you can comment on or make changes to this bug.