Bug 1211871 (CVE-2015-7195)

Certain escaped characters in host of Location-header are being treated as non-escaped

RESOLVED FIXED in Firefox 42

Status

()

defect
RESOLVED FIXED
4 years ago
3 years ago

People

(Reporter: frans, Assigned: valentin)

Tracking

({regression, sec-low})

41 Branch
mozilla44
Points:
---
Bug Flags:
sec-bounty -

Firefox Tracking Flags

(firefox41 wontfix, firefox42 fixed, firefox43 fixed, firefox44 fixed, firefox-esr38 unaffected)

Details

(Whiteboard: [post-critsmash-triage][adv-main42+])

Attachments

(4 attachments)

(Reporter)

Description

4 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/601.1.56 (KHTML, like Gecko) Version/9.0 Safari/601.1.56

Steps to reproduce:

I've identified that the latest version of Aurora 41 (Both on PC and Mac, 41.0.1) is treating URLs with escaped characters in the host of the Location header differently than previous versions.


Actual results:

The following header:
Location: http://example.com%0a%23.google.com/
Would in earlier versions result in an error. However in 41 it's actually redirecting you to http://example.com

In simple PHP code this means:
<? header("Location: http://example.com%0a%23.google.com/");

I have attached an image showing the Location-header of my test URL which resulted in a redirect to example.com

I've identified this issue on a couple of websites that do care about preventing Open Redirect issues (mostly because of non secured OAuth implementations using response_type=token, such as Facebook Connect). 

Previously these companies have been covered by the fact that the escaped characters in the subdomain of a host are throwing an error, but since Firefox now treats the characters differently, and sends the user to example.com, this is obviously not enough anymore for preventing an open redirect in Firefox.


Expected results:

I've checked the same redirect in IE, Chrome, Safari and earlier version of Firefox and this issue is not present in any of those browsers, they are either sending the user to the subdomain to Google.com (which is not a valid one of course) or resulting in an error. If I'm reading the RFC properly, these characters are not valid parts of a host thus an error is the correct way of handling a Location-header like this.

What's interesting here also is that this form of redirect to example.com is only possible through the Location-header. Both meta and javascript-redirects are resulting in an error instead.

Comment 1

4 years ago
I'm confused. What does "Aurora 41" mean? Firefox's publicly ("main", not beta/aurora or whatever) released version is 41 by now. Developer edition, which used to be Aurora, is 43. Can you reproduce this issue using a build from https://www.mozilla.org/firefox/all ? What about https://aurora.mozilla.org/ ?
Group: firefox-core-security → core-security
Component: Untriaged → Networking: HTTP
Flags: needinfo?(frans)
Product: Firefox → Core
(Reporter)

Comment 2

4 years ago
Hi,
Sorry for the confusion.

I've verified that the issue is present on:
Mac OS X, Firefox 41.0.1
Mac OS X, Firefox 43.0a2
Win, Firefox 41.0a2
Flags: needinfo?(frans)
(Reporter)

Updated

4 years ago
Summary: Certain escaped characters in host of Location-header are being treated as non-escaped in Aurora 41 → Certain escaped characters in host of Location-header are being treated as non-escaped

Comment 3

4 years ago
Anne, IIRC there's a new URL parsing spec (and code?) that you were working on. Is this likely to be related, and if so can you confirm whether this is a bug or expected?

Comment 4

4 years ago
It's not clear to me what might have caused this. Valentin might know. https://url.spec.whatwg.org/ does not allow for this behavior.
Flags: needinfo?(valentin.gosu)
I believe this is a regression from bug 1142083. (I hadn't anticipated this problem).
I think the best course of action is to back out that patch.
Flags: needinfo?(valentin.gosu)

Comment 6

4 years ago
Do we simply stop decoding when we hit an invalid byte?

Updated

4 years ago
Blocks: 1142083
Keywords: regression
Dan, how would you rate this?
Flags: sec-bounty?
I might be short-sighted here, but since a site can redirect you anywhere it doesn't seem too terrible as long as the URL bar represents where you really end up.

If we somehow ended up redirecting to the second half of a bogus URL like that then it's possible it could be injected by a third party into a redirecting URL that scans the first part to match the current domain, turning it into an unintended open redirect. But that's not what happens here. Maybe freddyb can be more creative but for now let's call it sec-low.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(dveditz)
Keywords: sec-low
(Assignee)

Updated

4 years ago
Assignee: nobody → valentin.gosu
Status: NEW → ASSIGNED
(Assignee)

Updated

4 years ago
Attachment #8672809 - Flags: review?(mcmanus)
Comment on attachment 8672809 [details] [diff] [review]
Backout bug 1142083

Review of attachment 8672809 [details] [diff] [review]:
-----------------------------------------------------------------

rs=mcmanus
Attachment #8672809 - Flags: review?(mcmanus) → review+
(Assignee)

Updated

4 years ago
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/4c9040d0d4d3
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla44
Group: core-security → core-security-release
Comment on attachment 8672809 [details] [diff] [review]
Backout bug 1142083

Approval Request Comment
[Feature/regressing bug #]:
Bug 1142083
[User impact if declined]:
Potential security issues as described in comment 0
[Describe test coverage new/current, TreeHerder]:
Tested manually.
[Risks and why]:
This is very low risk as it just reverts the patch in bug Bug 1142083.
[String/UUID change made/needed]:
None.
Attachment #8672809 - Flags: approval-mozilla-beta?
Attachment #8672809 - Flags: approval-mozilla-aurora?
Comment on attachment 8672809 [details] [diff] [review]
Backout bug 1142083

backout of a patch which introduced a regression, taking it.
Should be in 42 beta 8.
Attachment #8672809 - Flags: approval-mozilla-beta?
Attachment #8672809 - Flags: approval-mozilla-beta+
Attachment #8672809 - Flags: approval-mozilla-aurora?
Attachment #8672809 - Flags: approval-mozilla-aurora+
(Reporter)

Comment 18

4 years ago
I can confirm this is now fixed on 43.0a2 (2015-10-20).
Great job!
Regards,
Frans
(In reply to Daniel Veditz [:dveditz] from comment #8)
> I might be short-sighted here, but since a site can redirect you anywhere it
> doesn't seem too terrible as long as the URL bar represents where you really
> end up.
> 
> If we somehow ended up redirecting to the second half of a bogus URL like
> that then it's possible it could be injected by a third party into a
> redirecting URL that scans the first part to match the current domain,
> turning it into an unintended open redirect. But that's not what happens
> here. Maybe freddyb can be more creative but for now let's call it sec-low.

Nah, I fully agree.
Whiteboard: [post-critsmash-triage]
This is being minused for bounty as a "low" rated security issue. If the reporter can find a reason that this is misrated, let us know.
Flags: sec-bounty? → sec-bounty-
(Reporter)

Comment 21

4 years ago
Hi,
I noticed this due to the following attack scenario:

1. Website X allowed escaped characters in the subdomain part of the URL when doing a redirect. Their redirect scenario was allowing escaped characters in the subdomain. (Which you also can see as an issue)

Basically:
https://www.example.com?next=https://attacker.com%0a%23.example.com/
Resulted in:
Location: https://attacker.com%0a%23.example.com/

Now, at the same time they had a Facebook Connect solution through OAuth. Allowing the redirect_uri of the flow to be a arbitrary URL but had to be on the example.com domain.

So by chaining these two issues I was able to extract the OAuth token (using response_code=token) using the redirect_uri to their redirection page above, that then made the Location redirect which will maintain the token in the fragment to the attacker.com website.

This was only possible due to this specific error in the URL parsing, as there were no other way to escape out from their website.

I have not made any wider research on how many that were vulnerable the same way, but my guess is that they were validating the URL themselves, not using any public lib, which makes this case not that common.

So I'm totally fine with 'low' but wanted you to know the background info to the issue.
Whiteboard: [post-critsmash-triage] → [post-critsmash-triage][adv-main42+]
Alias: CVE-2015-7195
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.