1166874 - Security issue with URL transformations and Safe Browsing

Status: RESOLVED FIXED

(Toolkit :: Safe Browsing, defect, P2)

Description

[George]

Firefox treats special characters and does canonicalization of URLs differently than other browsers. The result of this is that upon manually entering or clicking on a URL, Firefox can end up on a different location than where Chrome or IE would end up. 

One case where this happens is when the URL contains a backslash '\'. 
Chrome and IE transform that to a slash '/', so www.example.edu/bad\url -> www.example.edu/bad/url
On the other hand, Firefox uses '\' as is, treating it as a regular character.

This difference can allow a malicious party to blindside security tools such as Safe Browsing.

To demonstrate this we submitted such URLs to be checked by Google through https://www.google.com/safebrowsing/report_badware/, which resulted in the transformed URL appearing in the DB of malicious URLs. But since Firefox does not do the transformation, a different URL is checked and the user is not prevented from accessing the malicious URL.

As a result, a malicious user can craft links that will lead Google safe browsing to check an innocuous page, while clicking through Firefox leads to a page containing malware.

Comment 1

[Gian-Carlo Pascutto [:gcp]]

I guess as a quick fix we could generate both versions here:
https://dxr.mozilla.org/mozilla-central/source/toolkit/components/url-classifier/LookupCache.cpp#419

There might be a wider question here regarding the different handling of URLs. If this is something we want to keep, we'll have to tell Google to keep URLs with backslashes as-is in the DB. If I understand correctly, the attack is that you would put malware on a page with a \, IE and Chrome would go to the / page (which might or might not have malware, but they'll warn if it has), and we'll go to the \ page but without ever warning.

Anne, are you the right person to ask: what's the status of the different handling of URLs? It his our bug? Is this an IE/Chrome bug? Is this something where we want to comply with web realities?

Comment 2

[Anne (:annevk)]

This is bug 652186 right? I guess the novelty here is the attack?

Comment 3

[Gian-Carlo Pascutto [:gcp]]

Yes indeed. It turns out that not agreeing on how an URL should look makes security databases useless. Given that this is a long-standing spec thing, I'll think we'll have to hack around it in SafeBrowsing.

Comment 4

[George]

It is true that according to the RFC, '\' should be an acceptable character. Probably chrome and IE decided to autocorrect it because users made mistakes typing and it turned to the concept of canonicalization, which is definitely more restrictive than the RFC. Still this is just speculation.

I wasn't aware that someone else also actually identified the '\' -> '/' as an issue in a different context: https://plus.google.com/+AlexisImperialLegrandGoogle/posts/EQXTzsBVS7L

The security problem here is that this transformation also occurs in when Safe browsing is scanning URLs. So the attack scenario is as follows:
1. The attacker serves malware, does phishing, etc. in a path containing a '\' 
2. When Google scans the page linking to the "bad" page, it visits the link after replacing '\' with '/'
3. The malware is hidden by Google and is accessible by Firefox users

The interesting thing is that the way things are now, whatever the attacker does, Firefox users are exposed. For example, if there is nothing in the URL with '/' Google thinks it is a broken link. Even if there is malware there and it is added in the malicious-sites DB, it is not the one that Firefox actually checks.

The proper solution would be for Google safe browsing to scan both the original link leaving backslashes untouched, and the link with the backslashes replaced.

Even if you want to manually submit a link containing a '\' to Google for scanning, you currently can't.

Comment 5

[Gian-Carlo Pascutto [:gcp]]

>2. When Google scans the page linking to the "bad" page, it visits the link after replacing '\' with '/'

Oh eew. That's right. This means that the SafeBrowsing spider potentially never sees the malware, which also means we can't work around it on the Firefox side.

Comment 6

[George]

I think that's the case. Actually, it is worse because '\' seems to be treated as an escape character when you submit a link manually.

We are writing a paper about all these stuff, so i would appreciate it if we could keep this bug private till the end of the summer. 

We also let Google know, so hopefully you guys can find a long-term solution.

Comment 7

[Anne (:annevk)]

The long term solution is fixing bug 652186 and making sure all URL parsers we use elsewhere conform to https://url.spec.whatwg.org/ so we don't get bitten again by parser differences.

Comment 8

[George]

(In reply to George from comment #6)
> I think that's the case. Actually, it is worse because '\' seems to be
> treated as an escape character when you submit a link manually.
> 
> We are writing a paper about all these stuff, so i would appreciate it if we
> could keep this bug private till the end of the summer. 
> 
> We also let Google know, so hopefully you guys can find a long-term solution.

The paper talking about this was accepted for publication at RAID15, so please go ahead and make this public if you wish.

Comment 9

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

Now that we fixed bug 652186 does this bug still apply?

Comment 10

[Daniel Veditz [:dveditz]]

François: you marked this P2, bug since bug 652186 is now fixed in Firefox 47 doesn't that fix this one, too?

Comment 11

[Gian-Carlo Pascutto [:gcp]]

I agree that fixing bug 652186 means this is no longer an issue.