Closed Bug 331942 Opened 19 years ago Closed 14 years ago

ObjectPrincipalFinder is not registered with the sandbox's context

Categories

(Core :: XPConnect, defect)

1.7 Branch
x86
Windows XP
defect
Not set
normal

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)

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.
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.
Attached patch HackSplinter Review
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.
Assignee: dbradley → mrbkap
Status: NEW → ASSIGNED
Attachment #216508 - Flags: review?(dveditz)
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.
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.)
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 on attachment 216508 [details] [diff] [review] Hack r=dveditz
Attachment #216508 - Flags: review?(dveditz) → review+
Attachment #216508 - Flags: superreview?(jst)
Attachment #216508 - Flags: superreview?(jst) → superreview+
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-
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
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
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
Group: core-security
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: