593 bytes, text/html
5.37 KB, patch
Ben Turner (not reading bugmail, use the needinfo flag!): review+
Ben Turner (not reading bugmail, use the needinfo flag!): superreview+
|Details | Diff | Splinter Review|
Created attachment 351526 [details] script Components.stack/Components.classes are supposed to be restricted from content Components.interfaces is supposed to be available (for historical reasons).
No need to let worker threads access Components.interfaces either, there's no legacy here. In fact, we shouldn't expose Components at all.
i've given ted a patch to try, if it works, i'd hope someone will commit it
Created attachment 351542 [details] [diff] [review] timeless' patch timeless asked me to test this patch he wrote. Without this patch, I see the contents of Components.classes in the test page here, with the patch I just see "hiReferenceError: Components is not defined".
Ugh, this was a todo that got forgotten... I'm sort of amazed that this works despite the JS_DeleteProperty. Clearly we need to check in a test case here.
On a side note, it seems that Worker is not subject to CAPS property access checks. user_pref("capability.policy.default.XMLHttpRequest.send", "noAccess"); works, user_pref("capability.policy.default.Worker.postMessage", "noAccess"); doesn't. Should we file a separate bug?
That has nothing to do with accessing the Components object, so yes :)
Support for that is more or less dropped everywhere, so I don't think there's need to do anything. However if you do think we should support it, or have a discussion about it, please file a separate bug or bring it to the newsgroup. It's definitely unrelated to this bug.
Comment on attachment 351542 [details] [diff] [review] timeless' patch Looks good!
bent: can you write a test for this? I'll push this change ASAP.
(In reply to comment #6) > I'm sort of amazed that this works despite the JS_DeleteProperty. Ugh, it's defined with JSPROP_PERMANENT. Patch with testcase coming up in a sec.
Created attachment 351606 [details] [diff] [review] Patch for checkin
(In reply to comment #13) > Created an attachment (id=351606) [details] > Patch for checkin How does the test's mention of Components alert watchers that there may be a security issue to be exploited? Can we check this test in while we are shipping vulnerable releases?
We should be checking the test in, yes. None of our stable releases are in fact vulnerable.
Pushed changeset 3d7f812792fb to mozilla-central.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Pushed changeset 92994c8da343 to mozilla-1.9.1.
Keywords: checkin-needed → fixed1.9.1
OS: Windows XP → All
Hardware: x86 → All
Target Milestone: --- → mozilla1.9.2a1
Component: DOM: Mozilla Extensions → DOM
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.