Closed Bug 1445844 (CVE-2019-11695) Opened 2 years ago Closed 1 year ago
Custom cursor goes outside the bounds of the web content in "malware" website
14.06 KB, text/html
903.01 KB, text/plain
1.50 KB, text/html
47 bytes, text/x-phabricator-request
|Details | Review|
264.67 KB, application/octet-stream
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0 Build ID: 20180206200532 Steps to reproduce: 1) Navigate to https://twomastersmedia.com/iops/?c5aa9d589430490ftfn1d5aa9d58943083=(888)%20498-4480# (note this is a website that tries to capture all events, so it's hard to get out of it) 2) Move the cursor around in the area with the red background 3) Move the cursor to the Firefox's top bar buttons (Home button / Hamburger Menu, etc) or Address bar. Click the mouse. Special note: keep slowly moving the mouse cursor upward toward the top of the screen, it will "go off the top" and then appear again slightly below the top bar. That's the "real cursor" and all clicks are registered by that. Actual results: Nothing happens, it appears the click is not registered. Note that if you click and drag downward a bit, it highlights some text on the webpage itself! Expected results: The click should have been received by Firefox. Note: it appears to be caused by a fake cursor - shouldn't Firefox prevent that somehow?
Hi bignis, I cannot access the link from the bug description (Status code: 404 Not Found), Step 1). Can you please check it or send me a link that I can access to reproduce the issue?
hmmmmm, I can still access the website. Attached is a cURL response from it when I used: curl "https://twomastersmedia.com/iops/?c5ab1b305c23f50ftfn1d5ab1b305c242e=(888)"%"20498-4480#" -H "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" --compressed -H "Accept-Language: en-US,en;q=0.5" -H "Cache-Control: max-age=0" -H "Connection: keep-alive" -H "Cookie: redirect=1" -H "DNT: 1" -H "Host: twomastersmedia.com" -H "Upgrade-Insecure-Requests: 1" -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0" here's a cURL HEAD request for just the headers in case it helps: curl "https://twomastersmedia.com/iops/?c5ab1b305c23f50ftfn1d5ab1b305c242e=(888)"%"20498-4480#" -H "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" --compressed -H "Accept-Language: en-US,en;q=0.5" -H "Cache-Control: max-age=0" -H "Connection: keep-alive" -H "Cookie: redirect=1" -H "DNT: 1" -H "Host: twomastersmedia.com" -H "Upgrade-Insecure-Requests: 1" -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0" -X HEAD -I HTTP/2 200 date: Wed, 21 Mar 2018 01:24:44 GMT content-type: text/html; charset=UTF-8 server: nginx p3p: CP='CAO DSP COR CUR ADM DEV TAI' cache-control: private, max-age=0, no-cache, no-store
In my opinion the behaviour is the malware site's fault and as far as I know Firefox has no special mechanism in place for this. My advice would be to avoid entering malware sites. Given the above, I'll close the issue es Invalid.
Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Resolution: --- → INVALID
David, just to make sure I've expressed my view of the problem clearly - do we expect Firefox to allow a custom cursor to be drawn over-top of the Address Bar in Firefox? Seems like a bad thing to me that the browser should disallow as it is being used by an evil website. Yeah, obviously avoiding the website is a good thing to do. The reason I filed this bug is because I believe it indicates a problem with the browser that this evil website is exploiting.
Hi Christoph, what do you think about this bug?
Flags: needinfo?(david.olah) → needinfo?(ckerschb)
(In reply to David Olah from comment #6) > Hi Christoph, what do you think about this bug? Dan might be in a better position to evaluate this bug. Dan, what do you think?
Flags: needinfo?(ckerschb) → needinfo?(dveditz)
This site is not blocked by SafeBrowsing. If we think it's a malicious site we should report it so it gets blocked. I get a 404 so thanks for recording and attaching the page. We should not allow custom cursors to escape the content area, especially not above the "Line of Death" into the chrome toolbar area as this site does. Firefox can't tell if a custom cursor is simply creative or if it's a "fake" (one that looks like the real cursor only offset). If the site is faking things inside their own web content that's one thing, but if that fake gets them to click (or not click) on actual browser chrome that can be a security issue. Another problem with fake cursors is getting the user to click on permission prompts, typically these days "door hangers" that bleed over the web content area. We need to keep these custom cursors out of those areas as well (harder!). In this example the "fake" cursor is above the real pointer location; in an attempt to lure a prompt click the fake image would be below or to the side of the real (invisible) pointer location. As used in this tech support scam example it's a "sec-low" spoof, but being able to spoof clicks onto permission prompts raises the stakes. In particular this could be used to get someone to install a malicious web extension or enable their camera and microphone.
Status: RESOLVED → REOPENED
Component: Untriaged → Layout
Ever confirmed: true
Product: Firefox → Core
Resolution: INVALID → ---
Summary: Custom cursor goes outside the bounds of the browser window in "malware" website → Custom cursor goes outside the bounds of the web content in "malware" website
Really interesting that everyone but me gets a 404. Makes me think the host is doing some kind of filtering to deny access to some. Anyway, the evil website is still working fine for me right now, so attaching a .HAR file of the content just in case it's needed (captured via Firefox's Web Developer Network tool).
The way this works is that they use a cursor image that's 128x128 pixels, and shows the arrow in the top-right corner, with the actual hotspot for the cursor being somewhere else. I'm not sure what we'd be able to do about this without breaking custom cursors entirely, besides limiting the size. I guess we could try to do more math on the layout size and remove the custom cursor if the cursor image starts overlapping the boundary of the content window? :dholbert, does that sound doable at all?
That sounds like a good approach, but I don't know enough about our cursor code to have an opinion on how doable it would be.
another example site which uses this to deliver malware: https://s3.amazonaws.com/gresrs/uk/index.html warning: malware.
Possibly related bug #1450083
> I'm not sure what we'd be able to do about this without breaking custom cursors entirely Could we not bound the cursor by its visible region? We cant just ban transparency but does seem like cropping out any large area of transparency / making sure the area the mouse is actually clicking has something visible would prevent this
(In reply to Dale Harvey (:daleharvey) from comment #16) > > I'm not sure what we'd be able to do about this without breaking custom cursors entirely > > Could we not bound the cursor by its visible region? We cant just ban > transparency but does seem like cropping out any large area of transparency > / making sure the area the mouse is actually clicking has something visible > would prevent this Well, as noted in earlier comments, the simplest way of fixing this is to just stop using the custom cursor when it overlaps with the chrome, even if the hotspot doesn't (yet). This wouldn't really affect "benign" custom cursors. The question is who knows our custom cursor code and whether that fix is feasible - if not, perhaps we could do what you're suggesting... Looks like Neil did the e10s support and Emilio did some pointer lock work. Maybe they can help.
I haven't done much cursor stuff actually, but I know some of the cursor bits. So what this is doing if I understand correctly is using a big cursor so that when the pointer is over content it seems it is over the chrome, right? So this should be an adequate test-case.
So, I think the place to fix this is around the widget code (nsIWidget::SetCursor). There we can check the bounds of the widget and the image, along with the hotspot, and just fall back to the default cursor or something. That's slightly annoying though, since the user could be hovering something that would usually have a pointer cursor or what not, and we wouldn't be able to fall back to it... Could we maybe clip the cursor to the widget instead during painting? I don't know. Looks like dbaron and smaug also have written / reviewed a bunch of the custom cursor stuff, so they may have opinions.
Assignee: nobody → emilio
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/d5850db1fb0d Add a pref to block large custom cursors outside of the viewport's bounds. r=smaug
You need to log in before you can comment on or make changes to this bug.