Bug 1321619 (CVE-2018-5111)

URL bar spoof using drag and drop (dnd) and unicode-lookalike protocol to drag plaintext that "looks like" a valid URL

RESOLVED FIXED in Firefox 58

Status

()

defect
P1
normal
RESOLVED FIXED
3 years ago
8 months ago

People

(Reporter: netfuzzerr, Assigned: Paolo)

Tracking

({csectype-spoof, sec-moderate})

unspecified
Firefox 58
Points:
---
Dependency tree / graph
Bug Flags:
sec-bounty -

Firefox Tracking Flags

(firefox-esr52 wontfix, firefox56 wontfix, firefox57 wontfix, firefox58 fixed)

Details

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

Attachments

(3 attachments)

Reporter

Description

3 years ago
Posted file poc.html
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.99 Safari/537.36

Steps to reproduce:

hey,

there's a url bar spoof vulnerability that occurs when a specially crafted url is dragged into the address bar.

Steps to reproduce:
1. Open poc.html(attached).
2. Drag and Drop the text in the page into the address bar.
3. notice that now is shown "https://www.google.com", even though the page hasn't been loaded.

cheers,
Mario.
Reporter

Comment 1

3 years ago
Posted image screenshot.png
screenshot demonstrating the vulnerability.

Updated

3 years ago
Component: Untriaged → Location Bar
Flags: sec-bounty?
Reporter

Comment 2

3 years ago
unhelpful
Is this being ignored?

Comment 3

3 years ago
(In reply to Mario Gomes from comment #2)
> Is this being ignored?

No. All of Mozilla is in conference this week, and will be (and traveling) until the begining of next week, so that impacts people being available to work/triage this.

From a quick look, this doesn't look like a complete spoof (security info (lock) isn't changed) and so this is sec-moderate or lower, so it isn't a "drop everything and fix this" kind of bug.

I also believe other patches I have in flight already might address this bug, but due to the above I just haven't had cycles to check that.

Comment 4

3 years ago
(In reply to :Gijs Kruitbosch from comment #3)
> I also believe other patches I have in flight already might address this
> bug, but due to the above I just haven't had cycles to check that.

This is no longer broken on today's nightly. I suspect my belief was right and that my fix for bug 791597 fixed it. I think I'd like to poke at this more though, feels like we should do more checks on the URI before even attempting to load it (and put it in the URL bar).

Comment 5

3 years ago
Oops, sorry for bugspam.
No longer blocks: CVE-2017-5417
Depends on: CVE-2017-5417
Giving it the rating for bug 791597, but it's probably a dupe of (and fixed by) that one.
Reporter

Comment 7

3 years ago
Any updates on this?

Comment 8

3 years ago
(In reply to Mario Gomes from comment #7)
> Any updates on this?

Any updates will appear in the bug. This is still on my list, but I'm on holiday right now. I don't believe this is critical - your testcase requires substantial user action and does not spoof the lock icon (so it's not a complete URL bar spoof). In that sense it's even less severe than 791597, which was sec-moderate.

The testcase doesn't currently work at all on Nightly, but I'm not sure if that will still be the case after I fix bug 1324410. I don't have time to test this right now (as I said, I'm on holiday). I'll look at it again after I get back, update the patch there and get it to land.
Comment hidden (off-topic)
Comment hidden (off-topic)
Comment hidden (off-topic)
Comment hidden (off-topic)

Comment 13

2 years ago
I was right in my suspicion that fixing bug 1324410 will make nightly vulnerable again.

I see several avenues we could pursue to fix this:

1) break all dragging to the URL bar. This is what Edge does. (I don't think this is a good idea. Something about the baby and the bathwater.)
2) break dragging plaintext to the URL bar. This is what IE does.
3) always search for non-URL drops. This is what Chrome does.
4) attempt to build some kind of heuristic to determine whether this is an attempt to spoof the user.


I don't think (4) is likely to work. There will always be more ways (specifically, more unicode characters) to spoof things than we can try to work around, and so I'm not particularly interested in trying. We do need to continue to support unicode typing and dragging to the URL bar for people who don't live in the English or other latin-charset-based languages, so I think that's a losing battle.

I would like to propose (3), with fallback to (2) if the user has toggled the hidden keyword.enabled pref, and while simultaneously improving our url fixup (e.g. bug 1181081) and using it explicitly in the dnd code, to mitigate cases where people "almost" drag a URL to the URL bar, like just dragging "google.com" or "/google.com" etc.

This is a change in UX, so I would like some buy-in from the UX team as well as Marco (with whom I've discussed this before now...) before working on this.

Philipp, the TL;DR here is that dragging arbitrary text to the URL bar and leaving it there is perceived to be a spoofing risk, especially because the user can't always control what the text is (websites can manipulate this). While Marco and I have discussed alternative solutions like showing the current page's URL when the URL bar is not focused (rather than the user's last input), that would likely be confusing and potentially break particular usage scenarios (drag text, then type) and/or not really fix the spoofing risk if users don't re-check the URL bar after re-focusing the content. So I listed some avenues above that we could explore. As noted, I would lean towards (3) unless you have strong objections. Please feel free to ping me on IRC (in private) if you have questions or if something is unclear. :-)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(philipp)
Flags: needinfo?(mak77)
Summary: URL Bar Spoof Using Drag&Drop → URL bar spoof using drag and drop (dnd) and unicode-lookalike protocol to drag plaintext that "looks like" a valid URL
(In reply to :Gijs from comment #13)
> I would like to propose (3), with fallback to (2) if the user has toggled
> the hidden keyword.enabled pref, and while simultaneously improving our url
> fixup (e.g. bug 1181081) and using it explicitly in the dnd code, to
> mitigate cases where people "almost" drag a URL to the URL bar, like just
> dragging "google.com" or "/google.com" etc.

Yep, we need to fixup the text, it would be sad to drop "www.mozilla.org" and run a search cause it's not a complete url.
Chrome is doing something similar, as I previously said, any text is automatically searched, unless it "looks like" a url, then it is fixed up and visited. I don't think there's any situation where they allow you to drop something in the urlbar and it stays there to be further edited. And in spite of this report, it makes sense as a behavior.

The only 2 problems I see:
1. UX change. User can't drag&drop a text, modify it to his likes and THEN start a search or a visit. This feature gets lost. On the other side, it sounds like an edge case, so we could just decide to take the hit.
2. D&D won't have the same behavior as C&P. IIRC we previously discussed this and there was some hint that we don't consider these 2 operations the same, in terms of spoof, cause C&P requires 2 actions and you see what you are copying (unless the web page populates the clipboard for you!). Before implementing a fix very specific to D&D, we should evaluate how much we care about C&P case, if we care a lot, maybe we need a broader approach? That said, if the patch here ends up being "simple" enough, we could take it regardless as a step forward.
Flags: needinfo?(mak77)

Comment 15

2 years ago
(In reply to Marco Bonardo [::mak] from comment #14)
> 2. D&D won't have the same behavior as C&P. IIRC we previously discussed
> this and there was some hint that we don't consider these 2 operations the
> same, in terms of spoof, cause C&P requires 2 actions and you see what you
> are copying (unless the web page populates the clipboard for you!). Before
> implementing a fix very specific to D&D, we should evaluate how much we care
> about C&P case, if we care a lot, maybe we need a broader approach? That
> said, if the patch here ends up being "simple" enough, we could take it
> regardless as a step forward.

Copy and paste is also more useful (in the location bar) right now than DND is. I paste things without wanting to use "paste and go" immediately, and then edit, also because paste gives you control over the insertion point, which we don't do for DND (even though on some OSes we'll show a cursor in the middle of the text while dragging :-\ ).
(In reply to :Gijs from comment #13)
> I was right in my suspicion that fixing bug 1324410 will make nightly
> vulnerable again.
> 
> I see several avenues we could pursue to fix this:
> 
> 1) break all dragging to the URL bar. This is what Edge does. (I don't think
> this is a good idea. Something about the baby and the bathwater.)
> 2) break dragging plaintext to the URL bar. This is what IE does.
> 3) always search for non-URL drops. This is what Chrome does.
> 4) attempt to build some kind of heuristic to determine whether this is an
> attempt to spoof the user.
> 
> 
> I don't think (4) is likely to work. There will always be more ways
> (specifically, more unicode characters) to spoof things than we can try to
> work around, and so I'm not particularly interested in trying. We do need to
> continue to support unicode typing and dragging to the URL bar for people
> who don't live in the English or other latin-charset-based languages, so I
> think that's a losing battle.
> 
> I would like to propose (3), with fallback to (2) if the user has toggled
> the hidden keyword.enabled pref, and while simultaneously improving our url
> fixup (e.g. bug 1181081) and using it explicitly in the dnd code, to
> mitigate cases where people "almost" drag a URL to the URL bar, like just
> dragging "google.com" or "/google.com" etc.
> 
> This is a change in UX, so I would like some buy-in from the UX team as well
> as Marco (with whom I've discussed this before now...) before working on
> this.
> 
> Philipp, the TL;DR here is that dragging arbitrary text to the URL bar and
> leaving it there is perceived to be a spoofing risk, especially because the
> user can't always control what the text is (websites can manipulate this).
> While Marco and I have discussed alternative solutions like showing the
> current page's URL when the URL bar is not focused (rather than the user's
> last input), that would likely be confusing and potentially break particular
> usage scenarios (drag text, then type) and/or not really fix the spoofing
> risk if users don't re-check the URL bar after re-focusing the content. So I
> listed some avenues above that we could explore. As noted, I would lean
> towards (3) unless you have strong objections. Please feel free to ping me
> on IRC (in private) if you have questions or if something is unclear. :-)

Thanks for the summary!
I agree with your proposal of going with 3) -- just tried this in Chrome and that behavior seems fine to me.
Flags: needinfo?(philipp)
Comment hidden (off-topic)
Comment hidden (off-topic)
Comment hidden (off-topic)
Comment hidden (off-topic)

Updated

2 years ago
Blocks: 1334455
Comment hidden (off-topic)
Priority: -- → P2

Updated

2 years ago
No longer blocks: 1334455
Comment hidden (off-topic)
Whiteboard: [fxsearch]
Does not spoof the lock icon and requires unconvincing user interaction: not paying a bounty (note, we did not pay for bug 791597 either).
Flags: sec-bounty? → sec-bounty-
Priority: P2 → P1
This is a P1 bug without an assignee. 

P1 are bugs which are being worked on for the current release cycle/iteration/sprint. 

If the bug is not assigned by Monday, 28 August, the bug's priority will be reset to '--'.
Keywords: stale-bug
Assigning to Paolo per our recent discussions.
Assignee: nobody → paolo.mozmail
Status: NEW → ASSIGNED
Assignee

Comment 26

2 years ago
Posted patch The patchSplinter Review
This executes the default action associated with the text that was dropped on the location bar, which is usually a search. If the "keyword.enabled" preference is false in about:config, this will perform a navigation, rather than disallowing the drop. This is because this preference is hidden, so I went with the simplest approach. I also haven't written an explicit test case for it.

I'll land this patch with the bug number once it's reviewed. I've started a tryserver build here:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=dbddea8e00797642f35270bd5d60b155dd8abe51
Attachment #8925542 - Flags: review?(mak77)
Comment on attachment 8925542 [details] [diff] [review]
The patch

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

Testing the Try build, it seems to be doing exactly what we expect, search or load url on drop. I'd like this to land asap, so we have about one full week of Nightly testing.

::: browser/base/content/test/urlbar/browser_dragdropURL.js
@@ +47,5 @@
>  });
>  
>  add_task(async function checkDragText() {
> +  await BrowserTestUtils.withNewTab(TEST_URL, async browser => {
> +    let promiseSearch = BrowserTestUtils.browserLoaded(browser, false, DRAG_TEXT_URL);

nit: maybe name it promiseLoad? in one case it's not a search
Attachment #8925542 - Flags: review?(mak77) → review+
Please remember to change the commit message to just the bug number and no description.
https://hg.mozilla.org/mozilla-central/rev/aa132747394e
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Keywords: stale-bug
Resolution: --- → FIXED
Target Milestone: --- → Firefox 58
Group: firefox-core-security → core-security-release
Whiteboard: [fxsearch] → [fxsearch][adv-main58+]
Alias: CVE-2018-5111
Whiteboard: [fxsearch][adv-main58+] → [fxsearch][adv-main58+][post-critsmash-triage]
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.