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)

x86
Windows XP
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla2.0
Tracking Status
firefox5 --- unaffected
blocking2.0 --- betaN+
blocking1.9.2 --- needed
status1.9.2 --- wanted
blocking1.9.1 --- needed
status1.9.1 --- wanted

People

(Reporter: moz_bug_r_a4, Assigned: mrbkap)

Details

(Whiteboard: [sg:critical][critsmash:patch])

Attachments

(1 file)

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.)
This works on Firefox trunk, 3.6.* and 3.5.*.
This works on SeaMonkey trunk, 2.0.*, Firefox 3.6.* and 3.5.*.
blocking1.9.2: --- → ?
blocking2.0: --- → ?
blocking1.9.1: --- → ?
Whiteboard: [sg:critical]
Whiteboard: [sg:critical] → [sg:critical][critsmash:investigating]
Assignee: nobody → mrbkap
Component: Security → XPConnect
QA Contact: toolkit → xpconnect
Attached patch Proposed fixSplinter Review
Attachment #451408 - Flags: review?(jst)
Attachment #451408 - Flags: review?(jst) → review+
blocking1.9.1: ? → .11+
blocking1.9.2: ? → .6+
Whiteboard: [sg:critical][critsmash:investigating] → [sg:critical][critsmash:patch]
time to land?
http://hg.mozilla.org/mozilla-central/rev/890b78ea868d
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Any hope for branch patches for this?
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.
blocking1.9.1: .11+ → needed
blocking1.9.2: .7+ → needed
blocking1.9.1: needed → .13+
blocking1.9.2: needed → .10+
blocking2.0: ? → betaN+
blocking1.9.1: .14+ → .15+
blocking1.9.2: .11+ → .12+
blocking1.9.1: .16+ → ?
blocking1.9.2: .13+ → ?
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.
blocking1.9.1: ? → .17+
blocking1.9.2: ? → .14+
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.
blocking1.9.1: .17+ → needed
blocking1.9.2: .14+ → needed
blocking1.9.1: needed → .18+
blocking1.9.2: needed → .15+
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+
The one-year anniversary punting to the next release
blocking1.9.1: .20+ → needed
blocking1.9.2: .18+ → .19+
blocking1.9.2: .20+ → needed
Summary: Chrome code using dataTransfer.mozGetDataAt() is potentially unsafe → Chrome code using dataTransfer.mozGetDataAt() leads to arbitrary code execution
Target Milestone: --- → mozilla2.0
The old testcases no longer work due to the fix in bug 723808.  I'll attach a new testcase.
This uses bug 344495's trick.
This works on fx 3.6.x.
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?
(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.
Marking as verified for trunk.
Assignee: mrbkap → nobody
Status: RESOLVED → VERIFIED
Component: XPConnect → XP Toolkit/Widgets: XUL
QA Contact: xpconnect → xptoolkit.xul
(I think these changes were accidental.)
Assignee: nobody → mrbkap
Component: XP Toolkit/Widgets: XUL → XPConnect
QA Contact: xptoolkit.xul → xpconnect
Group: core-security → core-security-release
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: