Closed
Bug 572130
Opened 14 years ago
Closed 14 years ago
Chrome code using dataTransfer.mozGetDataAt() leads to arbitrary code execution
Categories
(Core :: XPConnect, defect)
Tracking
()
VERIFIED
FIXED
mozilla2.0
People
(Reporter: moz_bug_r_a4, Assigned: mrbkap)
Details
(Whiteboard: [sg:critical][critsmash:patch])
Attachments
(1 file)
2.17 KB,
patch
|
jst
:
review+
|
Details | Diff | Splinter Review |
If a return value of dataTransfer.mozGetDataAt() is a content JS object, it is not wrapped in a SJOW. (If a return value is a content DOM object, it is wrapped in an XPCNativeWrapper.)
Reporter | ||
Comment 1•14 years ago
|
||
This works on Firefox trunk, 3.6.* and 3.5.*.
Reporter | ||
Comment 2•14 years ago
|
||
This works on SeaMonkey trunk, 2.0.*, Firefox 3.6.* and 3.5.*.
Updated•14 years ago
|
blocking1.9.2: --- → ?
blocking2.0: --- → ?
Updated•14 years ago
|
blocking1.9.1: --- → ?
Updated•14 years ago
|
Updated•14 years ago
|
Whiteboard: [sg:critical] → [sg:critical][critsmash:investigating]
Assignee | ||
Updated•14 years ago
|
Assignee: nobody → mrbkap
Component: Security → XPConnect
QA Contact: toolkit → xpconnect
Assignee | ||
Comment 3•14 years ago
|
||
Attachment #451408 -
Flags: review?(jst)
Updated•14 years ago
|
Attachment #451408 -
Flags: review?(jst) → review+
Updated•14 years ago
|
blocking1.9.1: ? → .11+
blocking1.9.2: ? → .6+
Updated•14 years ago
|
Whiteboard: [sg:critical][critsmash:investigating] → [sg:critical][critsmash:patch]
Comment 4•14 years ago
|
||
time to land?
Assignee | ||
Comment 5•14 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/890b78ea868d
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Talked to Blake about this one, we're going to punt for .7 & .11 as the fix uses a function that is not on the branches and we don't want the risk of backporting it at this time. We'll want it for a future security update though.
Updated•14 years ago
|
blocking1.9.1: needed → .13+
blocking1.9.2: needed → .10+
Updated•14 years ago
|
blocking2.0: ? → betaN+
Comment 8•14 years ago
|
||
Good thing we don't have 400 million people using vulnerable versions, guess we'll fix it next time. Next time being .14, seven releases after the comment 7 punt.
Updated•14 years ago
|
blocking1.9.1: ? → .17+
blocking1.9.2: ? → .14+
Comment 9•14 years ago
|
||
Blake, can I persuade you to work on a branch fix for this bug? We have a working PoC for arbitrary chrome code execution. We really should get this fixed ASAP.
Updated•13 years ago
|
blocking1.9.1: needed → .18+
blocking1.9.2: needed → .15+
Comment 10•13 years ago
|
||
Deferring to a future point release as we have run out of time. If this absolutely needs to be fixed and can land today or tomorrow, please send a note to release-drivers@mozilla.org
blocking1.9.1: .19+ → .20+
blocking1.9.2: .17+ → .18+
Comment 11•13 years ago
|
||
The one-year anniversary punting to the next release
blocking1.9.1: .20+ → needed
blocking1.9.2: .18+ → .19+
Updated•13 years ago
|
blocking1.9.2: .20+ → needed
Summary: Chrome code using dataTransfer.mozGetDataAt() is potentially unsafe → Chrome code using dataTransfer.mozGetDataAt() leads to arbitrary code execution
Updated•13 years ago
|
status-firefox5:
--- → unaffected
Target Milestone: --- → mozilla2.0
Reporter | ||
Comment 12•12 years ago
|
||
The old testcases no longer work due to the fix in bug 723808. I'll attach a new testcase.
Reporter | ||
Comment 13•12 years ago
|
||
This uses bug 344495's trick. This works on fx 3.6.x.
Comment 14•12 years ago
|
||
moz_bug_r, this probably isn't going to be fixed on 3.6.x at this point. Our last release was the final ever release, barring a chemspill. Is there anything in this bug that affects current Firefox versions?
Reporter | ||
Comment 15•12 years ago
|
||
(In reply to Al Billings [:abillings] from comment #14) > Is there anything in this bug that affects current Firefox versions? I think that there is nothing.
Comment 16•12 years ago
|
||
Marking as verified for trunk.
Assignee: mrbkap → nobody
Status: RESOLVED → VERIFIED
Component: XPConnect → XP Toolkit/Widgets: XUL
QA Contact: xpconnect → xptoolkit.xul
Assignee | ||
Comment 17•12 years ago
|
||
(I think these changes were accidental.)
Assignee: nobody → mrbkap
Component: XP Toolkit/Widgets: XUL → XPConnect
QA Contact: xptoolkit.xul → xpconnect
Updated•9 years ago
|
Group: core-security → core-security-release
Updated•9 years ago
|
Group: core-security-release
You need to log in
before you can comment on or make changes to this bug.
Description
•