Page can stomp on PRIMARY clipboard by calling select() at the right time

NEW
Assigned to

Status

()

Core
Selection
P3
critical
13 years ago
3 years ago

People

(Reporter: bz, Assigned: smaug)

Tracking

({sec-moderate})

Trunk
x86
Linux
sec-moderate
Points:
---
Bug Flags:
blocking1.8b3 -
blocking1.8b5 -
blocking1.9 -
wanted1.9 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:moderate], URL)

Attachments

(2 attachments)

BUILD: current trunk build (but this code has been around for a while...)

STEPS TO REPRODUCE:
1)  Make sure that you're running X (so highlighting text puts it in PRIMARY)
2)  Load testcase (or URL in URL field)
3)  Click in the textfield

EXPECTED RESULTS:
Text in textfield you click in is selected, but NOT in PRIMARY

ACTUAL RESULTS:
Text makes its way into PRIMARY

Note:  If the select() call is done in onclick, not onfocus, the bug is not
present.  So something is getting confused about the difference between
user-initiated selections and scripted selections.

I've not succeeded in getting this to reproduce by clicking outside the input
yet, but making a 0.0001-opacity input (which _would_ receive the click) track
the mouse pointer so it's below whereever the user clicks on the page is an easy
DHTML exercise.

Quite apart from the security implications, this makes the bugzilla sidebar a
pain to use -- any time I do a search with it it stomps on my PRIMARY.
Brian, any idea on this?
Nominating this.  Having pages be able to place arbitrary data into the
clipboard is a problem.  We really shouldn't ship any more releases with this.
Flags: blocking1.8b3?

Updated

13 years ago
Flags: blocking1.8b3? → blocking1.8b3+

Comment 3

13 years ago
->pavlov
Assignee: selection → pavlov

Comment 4

13 years ago
This isn't an X clipboard issue.  This is a problem with the selection code.
Presumably the code in
http://lxr.mozilla.org/seamonkey/source/layout/generic/nsSelection.cpp#7424
shouldn't get called in this case...

Updated

13 years ago
Assignee: pavlov → selection

Comment 5

13 years ago
daniel, or bryner (or bz) can any of you help with this? Is this even fixable?
It should be fixable, yes.  I can't help until I get back.  Then I wouldn't know
where to start.  Had I known where to even start looking at fixing this bug, I
would have had it fixed months ago -- this bug is a serious issue for my daily
bugzilla use...

Updated

13 years ago
Flags: blocking1.8b4+
Flags: blocking1.8b3-
Flags: blocking1.8b3+
Assignee: selection → dbaron
Target Milestone: --- → mozilla1.8beta3
That the event matters makes me suspect something funny with PostReason and
PopReason, although I'm also somewhat suspicious of the SELECTALL_REASON check
and the distinction between selection operations that post SELECTALL_REASON vs.
NO_REASON.
Actually, I don't think it's either; just that the script runs first and the
selection code tests whether the selection is collapsed rather than whether it
created the non-collapsed selection.
Maybe nsSelection::HandleClick shouldn't call PostReason.
But really PostReason/PopReason are broken and the reasons should be passed as
function arguments...
(In reply to comment #10)
> But really PostReason/PopReason are broken and the reasons should be passed as
> function arguments...

Well, I just tried a patch to do this, and it actually didn't help.
Created attachment 192862 [details]
testcase

Updated

12 years ago
Flags: blocking1.8b5+ → blocking1.8b5-
Flags: blocking1.9a1?

Updated

11 years ago
Assignee: dbaron → bzbarsky
Flags: blocking1.9a1? → blocking1.9-
Whiteboard: [wanted-1.9]

Updated

11 years ago
Whiteboard: [wanted-1.9] → [wanted-1.9] [sg:moderate]

Updated

10 years ago

Updated

10 years ago
Summary: Page can stomp on clipboard by calling select() at the right time → Page can stomp on PRIMARY clipboard by calling select() at the right time
Flags: wanted1.9+
Whiteboard: [wanted-1.9] [sg:moderate] → [sg:moderate]
The testcase doesn't work for me in Fx 3.  Is this still a valid bug?

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9) Gecko/2008052912 Firefox/3.0
Disregard comment 13.  Boris helped me understand the testcase better and the distinction between PRIMARY and CLIPBOARD.  The bug is definitely still valid.
Priority: -- → P2
Target Milestone: mozilla1.8beta3 → ---
It looks like a variant of Bug 55437.
No, not the same.  In this case, the text being selected is in fact what ends up in the PRIMARY... it's just not the _user_ who selected it.
For me the text is just selected but not copied to PRIMARY. (Fedora13/x86_64/FF3.6.8)
It's entirely possible this got fixed somewhere along the line.  I'll double check when I get the chance.
Priority: P2 → P3
Keywords: sec-moderate
Assignee: bzbarsky → bugs

Comment 19

4 years ago
I think this did get "fixed" at some point a few versions back, which broke sites like Google Maps since there's no longer any way of selecting the link text for the current map. Any field that calls select() from onclick becomes unselectable. See bug 926257 for details and test cases.
Hallvord, does the clipboard spec say anything about this, or should it?
Flags: needinfo?(hsteen)
No, this seems outside the scope of the clipboard spec. Also, in reply to comment 19, I don't think any intentional or unintentional "fix" for this caused bug 926257  - that's probably a separate bug that might mask this.
Flags: needinfo?(hsteen)
Created attachment 8569263 [details] [diff] [review]
hack

We could mark the selection as "tainted" if a script modifies the
selection between mouse-down/mouse-up and notify that as a change-
by-script rather than a change-by-user.  Then the copy to PRIMARY
thing does not occur.  Or some variation thereof.

(this hack seems to fix the bug for me locally, although I haven't
tested if it breaks anything else)
You need to log in before you can comment on or make changes to this bug.