Closed Bug 172673 Opened 23 years ago Closed 22 years ago

XBL executed with wrong permissions

Categories

(Core :: XBL, defect)

Product:
Core
Component:
XBL
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: hjtoi-bugzilla, Assigned: hyatt)

Details

Attachments

(2 files)

xbl file
458 bytes, text/xml
Details
xmlfile linking to previous attachment
323 bytes, text/xml
Details
Jonas will write better description :)
What's supposed to happen? What does happen with your build? I'm running 1.2alpha at the moment, and I see no alerts. /be
When opening attachment 101761 [details] directly i see two alerts, "this works" and "but this does not". This is the expeced and desired behaviour. However when downloading attachment 101761 [details] and loading it from file:// (still linking to the xbl on bugzilla) only the first alert is shown. When the second alert tries to execute it fails with a security error. When failing it is because we compare the http-prinicpal from bugzilla (where the binding comes from) with the file-principal from the page (where Window.alert lives). I am told that should not happen, the binding should fully execute with the permission of the page, i.e. we should never be using the http-pricipal. This is also a bit scary since if the binding is loaded from chrome we are at times using the chrome-principal. However there is still something blocking the script from executing with full chrome priviliges
A way to test all of this without having to put the xbl-file on a http-server somewhere is to put it in dist/bin/res and load it using the resources:// protocol
This is very scary indeed. Marking 1.2 blocker.
Whiteboard: [sg:blocker]
bryner or jag, can you help us with this one?
Why is this scary (from a security perspective), exactly? What we're seeing here is over-aggressive denial. The test case shows that a binding fails to execute with local permissions when it should. The only way that this is exploitable is if reversing the test case such that the document is remote, and the binding is local, causes the binding to execute with chrome privileges.
This is on the 1.2 list. What's the deal?
Sicking is on vacation until Nov 5, and it will then take a few more days before we can expect him back online.
OK, removing blocker status. We'll reevaluate this after sicking gets back.
No longer blocks: 1.2
Whiteboard: [sg:blocker]
Something here is wrong. As far as I can tell this bug is the exact opposite of bug 177639. So which is it? Is XBL executed in the security context of itself or of the document to which it is bound? See also bug 59701.
If I understand sicking's comments correctly, the XBL *should* be always executed with the principal of the content document, and sometimes it is, but sometimes it is executed with the principal of the XBL document. IMHO the best (i.e. safest) thing to do would be to fix bugs so that our current policy is fully enforced, i.e. XBL is always executed with the principal of the content document, and then provide an extension which allows designated XBL to execute with privileges.
XBL is supposed to execute with the privileges of the document that contains the bound element. This means the principal needs to be fixed up once per content document. In other words, if you have a prototype class A in XBL document D that ends up being bound to elements B and C in document E, then B and C get a new class A' with all the methods/properties of A cloned. If E is untrusted, A' will be untrusted. I can then come along with a trusted document F that has an element G that uses A. A new class A'' would be used by G, and A'' would also be trusted since F is trusted.
what input is needed from me? the first paragraph of comment 15 summs up the problem pretty well
From reading this drivers thinks that this isn't a current problem and want to take it off of our 1.2 radar. Dave, do you agree?
Yeah. The problem is that the permissions are too restrictive not less restrictive, so...
OK, off the 1.2 radar then.
Oh, and if this isn't a big security problem can we open this bug up?
is anybody *sure* this isn't a security problem. I only did some very basic testing where i failed to get chrome priviliges, but that was by no means enough to declare this a non-security-issue.
Hyatt, should we make this bug public?
We don't think this is a security bug, but there is a bug here where the check on <method/>s needs to be the same as the check on <constructor/>s.
See 196253 for the method/constructor bug, also see bug 195317.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → INVALID
Group: security
Why is this invalid? The problem described in comment 4 still occurs. There may not be a way to get too high priviliges here, but things defenetly don't work as they should.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: