Bug 1445844 was meant to fix this problem, but it has either regressed or was not entirely fixed. With a large custom cursor we do switch back to the real cursor when it goes out of bounds and overlays our UI, but there's quite a bit of slop. Nearly the entire addressbar is reachable on my Mac, enough to spoof clicking on the site info box.

POCs:

• attachment 9030715 [details]
• https://jameshfisher.github.io/cursory-hack/
• https://benjaminbenben.com/cursory-hack/
• http://cr.kungfoo.net/style/cursor/abusive-cursor.html

Given the above are all public there's not much point in hiding this bug, but it is an abusable spoofing vulnerability so I'll start off that way for now.

Chrome similarly fixed their version of this bug around the same time as our bug 1445844, and apparently has a similar offset issue. Below is a link to their patch, not so much for the code but for the comments in it. They didn't adjust the viewport correctly, and there's some inner code comments wondering what to do about iframes and how much to worry about compromised content processes if that's who is enforcing the boundaries. Also note that their and our code worries about "large" cursors > 32x32, but as some of the above cases show (especially the cr.kungfoo.net one) 32x32 is plenty big enough to cause trouble.

https://chromium.googlesource.com/chromium/src.git/+/827f22ba010c3304d0360227a64378ec79645278%5E%21/#F0

Although that patch is from July, it was recently assigned a CVE which may mean Chrome is going to release or announce this fix soon. Current Chrome fixes the attachment 9030715 [details] POC, but still appears vulnerable to the jameshfisher.github.io example. I haven't tried a dev version of Chrome.

Emilio: would this still be for you?

Yes, though I recall you told me about this last time some of these came up and I couldn't repro (and IIRC you couldn't repro on a clean profile either?).

I still can't repro, all those test-cases cause the expected behavior for me. Can you repro on a clean profile etc? If so, in which OS, and which OS version?

(Clearing ni? for now but if I manage to repro in any OS I'm happy to take a look :))

I can't reproduce it either, Nightly on Linux and OSX.

I can reproduce it in a clean profile on Mac Release 81 and an old profile on Mac Nightly. macos 10.15.6. The person reporting the Chrome bug was using Windows 10, but I haven't tried that.

Bouncing this back to Emilio per the discussion...

I'll try to repro locally on an OSX machine...

I couldn't repro, but I only have MacOS 11.0 beta... I tried both release an nightly on both my regular and a clean profile.

CC'ing more people - can anyone of you reproduce this issue?

(In reply to Mats Palmgren (:mats) from comment #9)

CC'ing more people - can anyone of you reproduce this issue?

On macOS 10.15 on the "kungfoo" testcase from comment #0, if I hover the yellow area, the 32x32px cursor overlaps the URL bar, on both Nightly and 82 beta.

Yeah, that's expected behavior given our prefs. If you change layout.cursor.block.max-size from 32 to 31 we start blocking.

I can reproduce on Linux with < 100% zoom.

Ah, good point, I can indeed reproduce that. That's worth fixing.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #11)

Yeah, that's expected behavior given our prefs. If you change layout.cursor.block.max-size from 32 to 31 we start blocking.

OK, but from comment 0's:

Also note that their and our code worries about "large" cursors > 32x32, but as some of the above cases show (especially the cr.kungfoo.net one) 32x32 is plenty big enough to cause trouble.

my reading was that Dan would like us to do something about this - I dunno if that's accurate though! I guess it sounds like we could reduce the pref number further, but I dunno if there are other/better options and/or what the downsides would be.

(In reply to :Gijs (he/him) from comment #10)

(In reply to Mats Palmgren (:mats) from comment #9)

CC'ing more people - can anyone of you reproduce this issue?

On macOS 10.15 on the "kungfoo" testcase from comment #0, if I hover the yellow area, the 32x32px cursor overlaps the URL bar, on both Nightly and 82 beta.

Agreed. Perhaps worth noting that this only reproduces with the bookmarks bar not displayed (if it's visible, then it provides enough separation that the cursor can no longer reach the URL bar).

Full zoom in the child process won't be applied to the cursor rect, so
undo it before checking to consider the actual rect that will be used.

(In reply to Jonathan Kew (:jfkthame) from comment #15)

Agreed. Perhaps worth noting that this only reproduces with the bookmarks bar not displayed (if it's visible, then it provides enough separation that the cursor can no longer reach the URL bar).

Sure, I think there's a tradeoff there between legit cursors and what not. It also overlaps the urlbar here on linux, but pretty minimally. If we want to change our prefs here that's ok, but that's different from comment 0, it seems that for Daniel the protection is not working at all.

Daniel, just checking, what are the values of layout.cursor.block.* prefs on your profile? Maybe something is tweaking them?

Maybe we should land that patch in a separate bug to avoid revealing the topic of this bug, since it's not a complete fix IIUC.

Undo full zoom in ShouldBlockCustomCursor. r=hiro
https://hg.mozilla.org/integration/autoland/rev/1346b92ae7a9a30e1941ecda041dce14d69dde5a
https://hg.mozilla.org/mozilla-central/rev/1346b92ae7a9

Perhaps worth noting that this only reproduces with the bookmarks bar not displayed (if it's visible, then it provides enough separation that the cursor can no longer reach the URL bar).

Collapsed bookmark bar has been the default for new profiles for a long time, so yes I'm concerned about the bleed over of a 32x32 cursor. Interesting that I tested in Safari and on the cr.kungfoo.net page they instantly revert to the real cursor when it touches the UI area (what I'd like) but they fail miserably with the benjaminbenben.com one -- they don't ever revert the cursor until the real cursor location touches the UI area.

Daniel, just checking, what are the values of layout.cursor.block.* prefs on your profile? Maybe something is tweaking them?

They are the default, true and 32

it seems that for Daniel the protection is not working at all.

I wouldn't say "at all". The protection fails to protect me from the "click on the lock" spoof at https://jameshfisher.github.io/cursory-hack/ when I don't have a bookmark bar, but if I push the fake cursor further up into the tab strip area then the real cursor is revealed (still in the content area). If I have a bookmark bar then the fake cursor can't get up to the URL bar. This defeats the spoof, but it hasn't been the default config for quite a while it seems.

I can reproduce on Linux with < 100% zoom.

What do you mean by "zoom"? I assume you don't mean page zoom (I wasn't using any). I've tried various larger and smaller scaled resolutions on my built-in 16" screen and a 27" external monitor and none of that seems to make the problem better or worse.

FWIW here is the chromium fix for the bug in the See Also:
https://chromium.googlesource.com/chromium/src.git/+/827f22ba010c3304d0360227a64378ec79645278

I'm sure the actual change doesn't help, but their comment was something about translating the cursor coordinate to the viewport offset not taking "OOPIFs" into account.

(In reply to Daniel Veditz [:dveditz] from comment #20)

I can reproduce on Linux with < 100% zoom.

What do you mean by "zoom"? I assume you don't mean page zoom (I wasn't using any). I've tried various larger and smaller scaled resolutions on my built-in 16" screen and a 27" external monitor and none of that seems to make the problem better or worse.

Full zoom I meant by pressing Ctrl+'+' or Ctrl+'-' (I don't know the shortcut key on Mac), that said it's a different issue what you are mentioning I believe.

The leave-open keyword is there and there is no activity for 6 months.
:emilio, maybe it's time to close this bug?

Daniel, is this still a problem for you? We never managed to reproduce your issue...

I can still totally reproduce it

• make sure bookmark toolbar is closed
• visit https://jameshfisher.github.io/cursory-hack/ and try to click the lock => chrome-style permissions doorhanger spoof pops up
• fresh profile on Firefox 88 Release (and other Firefox versions, of course, just putting a stake in the ground)
• 16-inch 2019 MBP running Mac 10.15.7
• the OS resolution doesn't matter (I'm using "default for display", but I tried bigger and smaller)
• cannot reproduce on Windows

Further oddness:

• I can reproduce on Chrome, despite their crbug.com/1099276 fix
• I can reproduce on Safari but behavior is slightly different. In the jameshfisher PoC the fake cursor is below the real one so it doesn't demonstrate the problem, but in https://benjaminbenben.com/cursory-hack/ the fake cursor stretches way further into the browser UI than it will on Firefox or Chrome before it reverts to the real cursor.

Tried on mac again (though running 11.3 beta), and still couldn't reproduce (only tried Nightly though).

The leave-open keyword is there and there is no activity for 6 months.
:emilio, maybe it's time to close this bug?

Can you still repro this Daniel?

I don't know what to say -- nothing has changed for me, and on my system I can reproduce the problem in basically all browsers: Firefox (release and nightly), Chrome, Edge. Safari has changed: the jamesfisher spoof doesn't really work, but the benjaminbenben one that used to be contained can now draw its cursor even over the OS menubar -- past the Safari window. Since I last tested I've upgraded to Big Sur. All except nightly were on clean profiles with no customizations (and I don't think my Nightly has anything that would affect this).

Pretty bizarre if I'm the only person who has a problem with https://jameshfisher.github.io/cursory-hack/ and https://benjaminbenben.com/cursory-hack/ but I don't know where to go from here.

If it repros on a clean profile I'm out of ideas. The only reason why it'd repro would be if you change layout.cursor.block.enabled or similar pref.

(In reply to Daniel Veditz [:dveditz] from comment #28)

I don't know what to say -- nothing has changed for me, and on my system I can reproduce the problem in basically all browsers: Firefox (release and nightly), Chrome, Edge. Safari has changed: the jamesfisher spoof doesn't really work, but the benjaminbenben one that used to be contained can now draw its cursor even over the OS menubar -- past the Safari window. Since I last tested I've upgraded to Big Sur. All except nightly were on clean profiles with no customizations (and I don't think my Nightly has anything that would affect this).

Pretty bizarre if I'm the only person who has a problem with https://jameshfisher.github.io/cursory-hack/ and https://benjaminbenben.com/cursory-hack/ but I don't know where to go from here.

Do you have your OS cursor set to be larger than the default? Can you do a screencast or similar showing what's happening?

Do you have your OS cursor set to be larger than the default? Can you do a screencast or similar showing what's happening?

Ah ha! that was exactly it -- I had increased the cursor size one notch above "Normal" because it's ridiculously small when I hook up my 4K monitor. When I reset the cursor zoom and then restart Firefox (the restart appears to be required) this all works correctly. I am so sorry for the wild goose chase since this fix last year.

(In reply to Daniel Veditz [:dveditz] from comment #31)

Do you have your OS cursor set to be larger than the default? Can you do a screencast or similar showing what's happening?

Ah ha! that was exactly it -- I had increased the cursor size one notch above "Normal" because it's ridiculously small when I hook up my 4K monitor. When I reset the cursor zoom and then restart Firefox (the restart appears to be required) this all works correctly. I am so sorry for the wild goose chase since this fix last year.

Doesn't that mean that the bug is fixed for default cursor sizes but not for increased ones? I'm not sure why cursor size impacts whether this bug is fixed and if there's something else we need to do on our side to make this work - for instance, if the OS is applying a scaling factor to the cursor rect, perhaps we need to apply the same scaling factor to the custom cursor before testing for overlap with the browser chrome? We can do this in a follow-up, as I imagine it'd need platform-dependent work to check for cursor scaling... Emilio, does that sound right or am I missing something?

(FWIW, I can easily reproduce Dan's experience by using the macOS prefs to increase cursor size)

I filed bug 1737751 per comment 32 in case we're able to tackle this issue for people with non-default cursor sizes

Yeah, I'll try to look at this in bug 1737751