Closed Bug 361298 Opened 18 years ago Closed 17 years ago

URL spoof using custom cursor with CSS3 hotspot

Categories

(Core :: Layout, defect)

1.8 Branch
x86
Windows XP
defect
Not set
normal

Tracking

()

VERIFIED FIXED

People

(Reporter: dvdckl, Assigned: roc)

References

(Depends on 1 open bug, )

Details

(Keywords: verified1.8.0.10, verified1.8.1.2, Whiteboard: [sg:moderate])

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0

The URL bar can be spoofed by using a large, mostly transparent custom cursor image and dynamically modifying the hotspot coordinates as per CSS3 specs (http://www.w3.org/TR/css3-ui/#cursor). Cursors will overflow outside of the browser content area. Affects Firefox 1.5 and later.

Reproducible: Always




This spoof will not work if the mouse cursor leaves the browser content area, and may not be pixel-perfect depending upon the users' configuration of Firefox.

Due to poor performance, it is not a viable option to leave the spoof URL image as a cursor constantly. It will cause an obvious jitter effect on the URL bar when the mouse is moved, especially if the spoof image is large to accommodate large browser windows. A cleverly crafted attack site would try to minimize the amount of mouse movement, and keep the mouse movement near the top of the page.
	
In the attached example, the spoof URL image is disabled when the mouse moves. This exposes the true URL while the mouse is moving, but a cleverly crafted host URL could make this "switch" appear to be a glitch causing a character to be transposed with another character, something many users may not even notice.
	
To be even more creative, one could dynamically generate spoof URL images using a canvas and toDataURL(). This would be useful to provide the illusion that the site is using encryption. Since the full URL bar would have to be overlayed with a yellow box and padlock icon, the image width could be determined dynamically, assuming that all users have the search box and "Go" button visible on their browser.
	
The attached example could use more fine tuning with regards to mouseover events due to the fake cursor image being displayed. For example, to make the status bar text persist for anchors when the mouse stops moving by wrapping the spoof cursor image in an anchor tag with the same href as the anchor below the image.
Attached file Proof of concept files
Attachment contents:
index.html
spoof.js
url.gif
arrow.png
pointer.png
text.png
You could get pretty close to perfectly spoofing an SSL site with this. Not sure we could get a fix in for the impending releases, but definitely want on the branches soon.
Assignee: nobody → dbaron
Status: UNCONFIRMED → NEW
Component: Security → Layout
Ever confirmed: true
Flags: wanted1.8.1.x+
Flags: wanted1.8.0.x+
Flags: blocking1.8.1.1?
Flags: blocking1.8.0.9?
Product: Firefox → Core
Whiteboard: [sg:moderate]
Version: unspecified → 1.8 Branch
Not blocking the releases for this, but we will take a patch if we can get some traction on this bug.
Flags: blocking1.8.1.1?
Flags: blocking1.8.1.1-
Flags: blocking1.8.0.9?
Flags: blocking1.8.0.9-
What exactly should we do here? We obviously need to restrict CSS3 cursors in some way, but how?
Can they be restricted so they appear only in the content area, and don't go outside of it?
That would be hard.

We probably could track the cursor size along with mouse events and if the cursor spills *above* the content area, disable it.
(In reply to comment #6)
> We probably could track the cursor size along with mouse events and if the
> cursor spills *above* the content area, disable it.

If this approach is used, you should test for overflow in all directions to prevent spoofing of the status bar and any unforeseen exploitations involving sidebars. This would also prevent the use of cursors to spoof events that appear to occur outside of the browser window, such as on the OS toolbar.
That would suck. Maybe we have no choice.
Unfortunately if we don't let the cursor spill over a little at least to the bottom and right then a typical "arrow replacement" cursor isn't going to be able to point at things near the bottom or right edges (or left if it's reversed).

Or is that what roc means would "suck"?

Would it make sense to limit the cursor image to a certain size range? The one in this spoof would be insane for an actual cursor. 64x64? 100x100? Would there be some way to restrict to make sure the hot-spot is near a non-transparent area and that there's no big gaps of transparency? (just dreaming here).
Flags: blocking1.8.1.2+
Flags: blocking1.8.0.10+
Yeah, that's what I meant by "would suck".

Restricting the size to 64x64 sounds good to me. Easy to implement, would make this infeasible to use in an exploit IMHO.
Assigning to roc.

roc:  code freeze is scheduled for next Thur. 1/18... could you get a patch together quickly for this?
Assignee: dbaron → roc
Attached patch simple approachSplinter Review
This is the simple approach. Works on GTK2, and presumably on Windows (can't test yet)
Attachment #251566 - Flags: superreview?(cbiesinger)
Attachment #251566 - Flags: review?(cbiesinger)
Whiteboard: [sg:moderate] → [sg:moderate] need r=biesi
Whiteboard: [sg:moderate] need r=biesi → [sg:moderate] need r=biesi/stuart
Comment on attachment 251566 [details] [diff] [review]
simple approach

We should at least scale the image down here or crop it.   Just erroring out is going to cause web authors confusion.
Attachment #251566 - Flags: superreview?(cbiesinger)
Attachment #251566 - Flags: superreview-
Attachment #251566 - Flags: review?(cbiesinger)
Attachment #251566 - Flags: review-
Are we going to get a tested scaling-down patch by Thursday? I don't mind confusing a few web authors who are trying big cursors if it prevents this spoof, and we can file a bug on making it nicer later.

64x64 might be a bit small. 100x100 or 128x128 would still prevent spoofing the url bar, you could only cover a bit of it only when you were pointing at the right part of the screen.

You could throw a message at the error console and call it done IMO.
> Are we going to get a tested scaling-down patch by Thursday?

Probably not for Windows, where I can't currently test.
So I guess it's up to Stuart to say what he's OK with...
lets do 128x128 for now and then try to get a patch to scale after this?
Stuart: is that an r=you for same patch with new numbers? if so a=dveditz for landing on the 1.8 and 1.8.0 branches.
Whiteboard: [sg:moderate] need r=biesi/stuart → [sg:moderate] need new patch
yeah, r/sr=me
Fixed on trunk and branches. Filed bug 368143 for the rescaling.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Whiteboard: [sg:moderate] need new patch → [sg:moderate]
Verified fixed on trunk.
I can see the issue in a 2007-01-24 build, but not anymore in a 2007-01-25.

Also verified that the spoof doesn't work in the latest branch builds.
Status: RESOLVED → VERIFIED
Group: security
Depends on: 398537
You need to log in before you can comment on or make changes to this bug.