Closed Bug 423541 (CVE-2008-2805) Opened 17 years ago Closed 16 years ago

Arbitrary file upload via originalTarget and DOM Range

Categories

(Core :: DOM: Core & HTML, defect, P2)

1.8 Branch
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: samuel.sidler+old, Assigned: smaug)

Details

(Keywords: testcase, verified1.8.1.15, Whiteboard: [sg:high])

Attachments

(1 file)

Attached file Testcase
As reported to security@ by Opera: While investigating potential file upload issues, one of our security researchers came across another vulnerability in Firefox. This is unrelated to the issues that we have previously reported to you. Attached. Exploiting the issue only requires one click (anywhere in the page), and one keypress (a-z, 0-9...any typed character works, although ctrl/shift/backspace/etc don't work). Filing in DOM:HTML since that's where bug 413135 was filed.
Flags: blocking1.9?
Flags: blocking1.8.1.14?
Jst, could we add a check to nsDOMClassInfo: if cx doesn't have system principal and .originalTarget is in native anonymous then return .target as .originalTarget.
Could we not do that in the originalTarget getter implementation instead?
But some native code which runs when there is content cx in stack may need the right originalTarget.
Then such code should push null on the JS context stack while calling code that depend on the context stack.
Can we get a security rating on this?
Does this really work on trunk? Getting references to the internal objects really shouldn't be able to get you anywhere on trunk.
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
I can't reproduce this on trunk, but can on 1.8. Samuel, you added the blocking1.9? Can you reproduce this on trunk?
Based on previous comment removing blocking. *Definitely* renominate if this can be reproduced on trunk though!
Flags: blocking1.9+ → blocking1.9-
(In reply to comment #7) > Samuel, you added the blocking1.9? Can you reproduce this on trunk? Apologies. That was a kneejerk reaction. I can't reproduce on trunk.
Version: Trunk → 1.8 Branch
Flags: blocking1.8.1.15? → blocking1.8.1.15+
Whiteboard: [sg:high]
-> Olli since he fixed bug 413135.
Assignee: nobody → Olli.Pettay
Status: NEW → ASSIGNED
Attached patch possible patchSplinter Review
I'll do still some testing but I think this might be good enough.
Comment on attachment 319352 [details] [diff] [review] possible patch I can't think any easier way to fix this. event.originalTarget isn't the only way to get access to native anon content. I know it sucks to put nsContentUtils::IsCallerTrustedForCapability("UniversalFileRead") to nsRange, but are there any other options?
Attachment #319352 - Flags: review?(jst)
Flags: in-testsuite?
Comment on attachment 319352 [details] [diff] [review] possible patch Seems reasonable for branch to me.
Attachment #319352 - Flags: review?(jst) → review+
Attachment #319352 - Flags: superreview?(jonas)
Jonas, could you perhaps sr this?
Attachment #319352 - Flags: superreview?(jonas) → superreview+
Attachment #319352 - Flags: approval1.8.1.15?
Comment on attachment 319352 [details] [diff] [review] possible patch Approved for 1.8.1.15, a=dveditz for release-drivers
Attachment #319352 - Flags: approval1.8.1.15? → approval1.8.1.15+
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Verified for 1.8.1.15 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.15pre) Gecko/2008061004 BonEcho/2.0.0.15pre.
Status: RESOLVED → VERIFIED
Alias: CVE-2008-2805
Group: security
Component: DOM: HTML → DOM: Core & HTML
Comment on attachment 319352 [details] [diff] [review] possible patch a=asac for 1.8.0
Attachment #319352 - Flags: approval1.8.0.next+
Flags: blocking1.8.0.next+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: