1648333 - (CVE-2020-15654) Deceptive custom cursor and infinite JavaScript loop causes Browser Lock effect

Status: VERIFIED FIXED

(Core :: Layout, defect)

Description

[yfsoph]

Attachment: demonstration video

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.106 Safari/537.36

Steps to reproduce:

1. Host index.html and cursor.png in the same directory
2. Navigate to index.html
3. Move mouse around until custom cursor is loaded
4. Move mouse over "hover here" until the text turns to "ok"
5. Try to click Back/Close Tab buttons
6. Try to click "Stop It" when the "A web page is slowing down..." doorhanger notification pops up

Actual results:

Browser Lock effect: buttons are seemingly not clickable, website is not easy to get away from

Expected results:

Custom cursor should not be active near browser Back/Close Tab buttons, or the "A web page is slowing down..." notification

Comment 1

[yfsoph]

Attachment: index.html

Comment 2

[yfsoph]

Attachment: cursor.png

Comment 3

[yfsoph]

If JavaScript code runs in an infinite loop while a deceptive custom cursor is active in a web page, the mitigations applied in bug 1445844 are rendered ineffective and a Browser Lock effect happens, in a similar fashion to this same bug.
Mitigation code from bug 1445844 (e.g. function ShouldBlockCustomCursor) is meant to be triggered inside the content process as a result of mouse events, that are not being handled when JavaScript is busy executing an infinite loop.
The process hang monitor notification is also under the deceptive custom cursor effect and thus the force stopping of the infinite loop execution is prevented. This part is possibly related to bug 1538402

Comment 4

[yfsoph]

Note: It's possible to break out of the Browser Lock effect when the mouse moves out of the browser's window. Therefore it's most effective when browser is in full screen.

Comment 5

[Emilio Cobos Álvarez (:emilio)]

Hmm, right, so the issue is that we're doing the "is cursor in bounds" check in the child process (which is needed if you want our current fallback behavior).

But the child process is too busy to process the mouse moves doing nothing... Chrome's implementation has the same issue looks like.

I guess we could move the check to the parent process, and only fall back to the next built-in cursor rather than to the next image cursor. Or something like that?

Comment 6

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1648333 - Make sure there's no custom cursor when popping up the slow script dialog. r=Gijs

Comment 7

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/integration/autoland/rev/c06ea431e99890725f62f05487c8736eac6937d2
https://hg.mozilla.org/mozilla-central/rev/c06ea431e998

Comment 8

[Ryan VanderMeulen [:RyanVM]]

Please nominate this for ESR78 approval when you get a chance.

Comment 9

[Emilio Cobos Álvarez (:emilio)]

Comment on attachment 9159372 [details]
Bug 1648333 - Make sure there's no custom cursor when popping up the slow script dialog. r=Gijs

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Easy sec-low.
• User impact if declined: comment 0
• Fix Landed on Version: 79
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): One liner that ensures we get a non-custom cursor when the slow script dialog pops up.
• String or UUID changes made by this patch: none

Comment 10

[Alexandru Trif, Desktop QA [:atrif]]

Reproduced the issue using Firefox 79.0a1 (20200624215010) on Windows 10x64 and steps from comment 0.
No custom cursor is shown when the slow script dialog is displayed using Firefox 79.0b2 (20200630191632) on Windows 10x64, macOS 10.12, and Ubuntu 18.04.

Comment 11

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9159372 [details]
Bug 1648333 - Make sure there's no custom cursor when popping up the slow script dialog. r=Gijs

Approved for 78.1esr.

Comment 12

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr78/rev/33eebaed392a

Comment 13

[Cristian Fogel [:cfogel]]

Verified with the task cluster builds for ESR as well.

Comment 14

[Frederik Braun [:freddy]]

Attachment: advisory.txt

Comment 15

[Frederik Braun [:freddy]]

Thank you for reporting this issue!
Please see the attached advisory and let us know asap, if you wanted to be credited differently.

Comment 16

[yfsoph]

(In reply to Frederik Braun [:freddy] from comment #15)

Thank you for reporting this issue!
Please see the attached advisory and let us know asap, if you wanted to be credited differently.

Thanks! Please credit "SophosLabs Offensive Security team"

Comment 17

[Emilio Cobos Álvarez (:emilio)]

Freddy, can you update the advisory to also mention the "infinite Javascript loop" / "content process hang" bit? It is a requirement, because otherwise we already prevent the cursor from overflowing the viewport if it's too large, see bug 1445844.

Comment 18

[Frederik Braun [:freddy]]

Done and done.