If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Restricted access requested and granted for local script, not remembered correctly.

RESOLVED DUPLICATE of bug 427051

Status

()

Firefox
Security
RESOLVED DUPLICATE of bug 427051
8 years ago
8 years ago

People

(Reporter: avih, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6

When a local script (on the user's file system) uses netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect"); , The dialog that asks the user to grant/remember doesn't show the full URI but only "file://". This is also the data that's being saved to prefs.js ( user_pref("capability.principal.codebase.p1.id", "file://"); ), seemingly granting the privilege to an entire protocol.

As far as I can tell, it's not exploitable: on later sessions of Firefox this grant seems to be ignored (probably sanity checks that won't grant privs to an entire protocol). This also causes the same script to issue the privs request dialog again, even if was approved and set to "remember this choice".

Reproducible: Always

Steps to Reproduce:
1. Create a local file "privileges.html" with the following content:
-----------------------------
<html><body><script>
netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect");
</script></body></html>
-----------------------------

2. Load it into the browser. At the security dialog, Check "Remember this decision" and click "Allow".

3. Restart the browser and open "privileges.html" again.
Actual Results:  
1. The URI for approval on the security dialogs is "file://".

2. The dialog appears also after restart (The "remember this choice" checkbox is not respected).

3. prefs.js contain the triplets:
user_pref("capability.principal.codebase.p1.granted", "UniversalXPConnect");
user_pref("capability.principal.codebase.p1.id", "file://");
user_pref("capability.principal.codebase.p1.subjectName", "");

for each such new approval (p<n> ever increasing for each approval, for the same script!)

Expected Results:  
1. The proper URI is shown for approval e.g. "file://c:/privileges.html" (not "file://")

2. If the user checks "remember", the dialog will not appear again for the same file.

3. prefs.js would contain only one triplet for this file, with proper URI.

If I manually delete all the triplets except for p0, and set the URI correctly for p0, the access IS respected on next sessions and the security dialog doesn't show again.

The "remember" checkbox IS respected while in the same session (i.e. close the file and re-open it without restarting firefox - not asked again), and if it's not set to "remember", then the dialog pops on every reload of the page.
(Reporter)

Comment 1

8 years ago
Looks like the same issue, but for "http://localhost" URIs, mentioned almost 2 years ago on MozillaZine : http://forums.mozillazine.org/viewtopic.php?p=3790595#p3790595 .
(Reporter)

Comment 2

8 years ago
Also, when I access the same file via a local web server, it denies the grant withOUT ever asking the user for approval. This is what appears at the error console:

Error: A script from "http://localhost" was denied UniversalXPConnect privileges.
Source file: http://localhost/privileges.html
Line: 2
(Reporter)

Comment 3

8 years ago
I think comment 1 and comment 2 are not strictly related since security is different for http:// and file:// protocols. However, it's possible that because privileges are domain based for http://, the same code breaks when it tries to handle the domain-less file:// protocol. Possibly.

Anyway, I'll leave the assumptions for the pro's...

Updated

8 years ago
Status: UNCONFIRMED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 427051
You need to log in before you can comment on or make changes to this bug.