1211871 - (CVE-2015-7195) Certain escaped characters in host of Location-header are being treated as non-escaped

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect)

Description

[Frans Rosén]

Attachment: SuccessWithLocationRedirect.png

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

[:Gijs (he/him)]

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/ ?

Comment 2

[Frans Rosén]

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

Comment 3

[Benjamin Smedberg]

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

[Anne (:annevk)]

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.

Comment 5

[Valentin Gosu [:valentin] (he/him)]

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.

Comment 6

[Anne (:annevk)]

Do we simply stop decoding when we hit an invalid byte?

Comment 7

[Andrew McCreight [:mccr8]]

Dan, how would you rate this?

Comment 8

[Daniel Veditz [:dveditz]]

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.

Comment 9

[Valentin Gosu [:valentin] (he/him)]

Attachment: Backout bug 1142083

Comment 10

[Patrick McManus [:mcmanus]]

Comment on attachment 8672809 [details] [diff] [review]
Backout bug 1142083

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

rs=mcmanus

Comment 11

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/4c9040d0d4d3

Comment 12

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/4c9040d0d4d3

Comment 13

[Valentin Gosu [:valentin] (he/him)]

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.

Comment 14

[Sylvestre Ledru [:Sylvestre]]

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.

Comment 15

[Valentin Gosu [:valentin] (he/him)]

Attachment: backout_location_decoding_aurora.patch

Comment 16

[Valentin Gosu [:valentin] (he/him)]

Attachment: backout_location_decoding_beta.patch

Comment 17

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/684374b774ab
https://hg.mozilla.org/releases/mozilla-beta/rev/32de6f21dd48

Comment 18

[Frans Rosén]

I can confirm this is now fixed on 43.0a2 (2015-10-20).
Great job!
Regards,
Frans

Comment 19

[Frederik Braun [:freddy]]

(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.

Comment 20

[Al Billings [:abillings - ex-MoCo]]

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.

Comment 21

[Frans Rosén]

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.