Closed
Bug 331942
Opened 19 years ago
Closed 14 years ago
ObjectPrincipalFinder is not registered with the sandbox's context
Categories
(Core :: XPConnect, defect)
Tracking
()
RESOLVED
WORKSFORME
Tracking | Status | |
---|---|---|
status1.9.2 | --- | unaffected |
status1.9.1 | --- | unaffected |
People
(Reporter: moz_bug_r_a4, Unassigned)
Details
(Whiteboard: [sg:moderate] (code execution in PAC))
Attachments
(2 files)
501 bytes,
text/plain
|
Details | |
3.94 KB,
patch
|
dveditz
:
review+
jst
:
superreview+
|
Details | Diff | Splinter Review |
In 1.0.x, the sandbox's context's findObjectPrincipals is null, thus,
js_CheckPrincipalsAccess always returns JS_TRUE. This means that the
belt-and-braces don't work as intended in the sandbox.
Reporter | ||
Comment 1•19 years ago
|
||
Steps to Reproduce:
1. Setup a PAC file testcase on web server, or save it to local hard disk.
2. Set Automatic proxy configuration URL to its URL.
3. Open any web site.
An alert dialog that shows Components.stack will appear.
Also, see Bug 311025.
Comment 2•19 years ago
|
||
This is ugly as sin, but it fixes the bug and there's no obvious way to share the code between the two modules. This is not on a performance-critical path and I'm not sure I care to find a better way to share the code.
Comment 3•19 years ago
|
||
Also, I'm not sure if this bug alone is worth respinning for. There are other methods of attack, and I'm not sure how much we do or don't trust the code being compiled from PAC.
Comment 4•19 years ago
|
||
FWIW, my opinion is that a PAC-requiring vuln is not worthy of a respin; PAC has always been able to do some pretty ugly things if it were hostile. (Though the sandboxing *is* there for a reason, and we should try to make it live up to its promise.)
Comment 5•19 years ago
|
||
Bug 321101 is a similar PAC privilege escalation, but not ready to land. Probably not respinning just for this if we're leaving the other open, but if we have to respin 1.0.8/1.7.13 for bug 331943 then maybe we should take this too.
Flags: blocking1.7.14+
Flags: blocking1.7.13?
Flags: blocking-aviary1.0.9+
Flags: blocking-aviary1.0.8?
Whiteboard: [sg:moderate] (code execution in PAC)
Comment 6•19 years ago
|
||
Comment on attachment 216508 [details] [diff] [review]
Hack
r=dveditz
Attachment #216508 -
Flags: review?(dveditz) → review+
Updated•19 years ago
|
Attachment #216508 -
Flags: superreview?(jst)
Comment 7•19 years ago
|
||
Comment on attachment 216508 [details] [diff] [review]
Hack
sr=jst
Attachment #216508 -
Flags: superreview?(jst) → superreview+
Comment 8•19 years ago
|
||
After discussions with Schrep, dveditz, mrbkap, darin we decided that we have it is not critical to add this bug to 1.0.8/1.7.13. There is at least one other similar bug we already passed on for these releases. We plan to crack open the build for bug 33194. But we want to keep that, yet another respin, *extremely* limited.
Flags: blocking1.7.13?
Flags: blocking1.7.13-
Flags: blocking-aviary1.0.8?
Flags: blocking-aviary1.0.8-
Comment 9•19 years ago
|
||
Since this only affects the old branches, I'm not going to own this bug any more. If someone wants this patch (which should apply cleanly) on the 1.7 branches, then they'll have to check it in.
Assignee: mrbkap → nobody
Status: ASSIGNED → NEW
Updated•14 years ago
|
Status: NEW → RESOLVED
Closed: 14 years ago
status1.9.1:
--- → unaffected
status1.9.2:
--- → unaffected
Resolution: --- → WONTFIX
Comment 10•14 years ago
|
||
Actually this was fixed long ago so "worksforme" is a better resolution. "Wontfix" applies to fixing this on the 1.7 branch which is ancient and unused.
Resolution: WONTFIX → WORKSFORME
Updated•14 years ago
|
Group: core-security
You need to log in
before you can comment on or make changes to this bug.
Description
•