Created attachment 310115 [details] 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.
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.
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!
(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.
-> Olli since he fixed bug 413135.
Created attachment 319352 [details] [diff] [review] possible patch 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?
9 years ago
Comment on attachment 319352 [details] [diff] [review] possible patch Seems reasonable for branch to me.
Jonas, could you perhaps sr this?
Comment on attachment 319352 [details] [diff] [review] possible patch Approved for 184.108.40.206, a=dveditz for release-drivers
Verified for 220.127.116.11 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:18.104.22.168pre) Gecko/2008061004 BonEcho/22.214.171.124pre.
Comment on attachment 319352 [details] [diff] [review] possible patch a=asac for 1.8.0