1242232 - Backslash or doublequote in location bar not escaped, can affect JSON interpretation

Status: RESOLVED DUPLICATE of bug 1233672

(Firefox :: Address Bar, defect)

Description

[Josh Triplett]

In Firefox 43, the top entry in the location bar shows what hitting Enter would do: either search for the typed string, or visit it as an URL if it looks like an URL.  In the latter case, Firefox does not properly escape the string.

In the examples below, I've quoted text using vertical bars ||, to avoid ambiguity with text containing various special characters.

Typing |https://mozilla.org/| in the location bar will show |Visit https://mozilla.org/| in the top entry, as expected.

Add a trailing backslash, |https://mozilla.org/\|, and the top entry shows |Visit {"url":"https://mozilla.org/\","input":"https://mozilla.org/\\"}|

Add a trailing doublequote instead, |https://mozilla.org/"|, and the top entry shows |Visit {"url":"https://mozilla.org/"","input":"https://mozilla.org/\""}|

To prove that this allows modifying the JSON data structure: type |https://mozilla.org/","url":"example.com|, and the top entry shows |Visit example.com|.

Backslash string escapes also work: |https://mozilla.org/\u0020| shows a space in that spot, and |https://mozilla.org/\u0000| shows a Unicode replacement square with 0000 in it.

Other JSON types work: |https://www.mozilla.org/","url":1e6,"some-key":"foo| shows |Visit 1000000| (parsing the exponential notation), |https://www.mozilla.org/","url":null,"some-key":"foo| just shows |Visit |, and |https://www.mozilla.org/","url":["foo","bar"],"some-key":"foo| shows |Visit foo,bar| (having parsed the list).

Comment 1

[:Gijs (he/him)]

Marco, can you look into this?

Josh, this is all manual user input, right? What exactly is the security impact here? Unless there's a serious security issue here, we should open up the bug so more people can see it and/or help.

Comment 2

[Josh Triplett]

Gijs: Copying and pasting into the location bar will produce the same results.  I marked this as a security bug for a few reasons.  Consider the history that led to disabling "javascript:" URIs in the location bar, because people fell for traps involving copying and pasting malicious URIs (e.g. "copy this into your location bar and press enter to get an invite to the secret beta of the Facebook dislike button").  At a minimum, this bug provides a mild form of spoofing to help people attempting phishing or other social engineering: for instance, "Remember to always copy and paste URLs like this from email for safety; to confirm that it's safe, notice that your browser says 'Visit Mozilla to update Firefox' before pressing enter."  Put that with a URL that starts with "mozilla-firefox-critical-update" or similar, and you'd have a more effective scam.  We've taught people to trust what the browser's chrome displays, rather than what sites display; this could abuse that.

However, I primarily marked this as a security bug until we have confirmation that no arbitrary modifications to that data structure (changing or adding arbitrary keys/values) could produce any kind of JavaScript code execution or other bad behavior (whether with chrome permisisons or as the current page).  I poked around in toolkit/content/widgets/autocomplete.xml a bit, but it has enough interesting cases of things it can do from the location bar based off of various properties that I didn't want to assume this couldn't possibly lead to any misbehavior.  Hence the security bug while that investigation occurred.

If we can confirm that no possible copy/pasted value can cause the location bar or autocomplete widgets to misbehave in any way worse than spoofing of the autocomplete result, then that spoofing alone seems sec-low at most, and sufficiently mild that opening up the bug seems fine.

Comment 3

[Marco Bonardo [:mak]]

This is already known and we are working on it in bug 1233672.

I think the worse thing can happen here (and the reason we set it to P1) is that you can hide the real destination url with a fake one. So it's social spoofing, one could copy into the clipboard a well-shaped json object that when pasted would show "Visit site.com" when it will instead navigate to site.com.
There should be no execution risk apart that, all the properties in that object are used as simple labels and used as such.

Comment 4

[Marco Bonardo [:mak]]

(In reply to Marco Bonardo [::mak] from comment #3)
> when pasted would show "Visit site.com" when it will instead navigate to
> site.com.

The second site.com was intended to be "othersite.com", sorry for the typo.

Comment 5

[Josh Triplett]

(In reply to Marco Bonardo [::mak] from comment #3)
> This is already known and we are working on it in bug 1233672.
[...]
> There should be no execution risk apart that, all the properties in that object are used as simple labels and used as such.

OK, then feel free to un-hide this bug and mark it as a duplicate of 1233672.  Hopefully the test cases in comment #0 will help in the development of the new test.

Comment 6

[Marco Bonardo [:mak]]

I'll let Drew evaluate whether is worth integrating more of those test-cases in the newly added test.

Comment 7

[Drew Willcoxon :adw]

Thanks Josh, I'm using your test cases in the new test (and they all pass, whew).