The default bug view has changed. See this FAQ.
Bug 680880 (CVE-2011-3647)

Security problem with loadSubScript on 1.9.2 branch

VERIFIED FIXED

Status

()

Core
Security
VERIFIED FIXED
6 years ago
5 years ago

People

(Reporter: moz_bug_r_a4, Assigned: mrbkap)

Tracking

({verified-aurora, verified-beta})

1.9.2 Branch
x86
Windows XP
verified-aurora, verified-beta
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox6- wontfix, firefox7- fixed, firefox8+ fixed, firefox9+ fixed, blocking1.9.2 .24+, status1.9.2 .24-fixed)

Details

(Whiteboard: [sg:critical][qa!] patch in bug 653926)

(Reporter)

Description

6 years ago
On 1.9.2, using loadSubScript with a content object as the scope object is
potentially unsafe.

On 1.9.2, the parent chain of XPCNativeWrapper/SJOW reaches to a content
window, thus the subscript can directly access content objects.

For example:
* An object created in the subscript is not a SJOW.
* When the scope object is an XPCNativeWrapper, "document" is not an XPCNativeWrapper.
  in subscript:
  window.toString() -> [object XPCNativeWrapper [object Window]]
  window.document.toString() -> [object XPCNativeWrapper [object HTMLDocument]]
  document.toString() -> [object HTMLDocument]
(Reporter)

Comment 1

6 years ago
Created attachment 554841 [details]
test extension
(Reporter)

Comment 2

6 years ago
Created attachment 554842 [details]
testcase - arbitrary code execution

This works in Firefox 3.6.20 (and 5, 6, 7 due to bug 653926).
Assignee: nobody → mrbkap
Whiteboard: [sg:critical]
Version: unspecified → 1.9.2 Branch

Updated

6 years ago
status-firefox6: --- → unaffected
status-firefox7: --- → unaffected
status-firefox8: --- → unaffected
status-firefox9: --- → unaffected
tracking-firefox6: --- → -
tracking-firefox7: --- → -
tracking-firefox8: --- → -
tracking-firefox9: --- → -
blocking1.9.2: --- → ?
status1.9.2: --- → wanted
Hopefully Firefox 7 and later are fixed by bug 653926 but setting it to track those releases to make sure.

mrbkap: is there anything in the fix for bug 653926 that can be applied to the 1.9.2 branch or do you have to come up with something else? Or is fixing it even possible?
blocking1.9.2: ? → .21+
status-firefox6: unaffected → affected
status-firefox7: unaffected → affected
status-firefox8: unaffected → affected
status-firefox9: unaffected → affected
tracking-firefox7: - → +
tracking-firefox8: - → +
tracking-firefox9: - → +
qa, can we get help verifying that this is fixed for 7 and beyond? Please see previous comment.
Keywords: qawanted
moz_bug: Can you help QA with verification steps? I installed the extension but it is unclear what we are supposed to see. Thanks.
(Reporter)

Comment 6

6 years ago
Steps to reproduce:
1. Install "test extension".
2. Load the testcase.
3. Click "test" button on the top of the browser's toolbox.
a) If the bug is not fixed, an alert dialog that shows Components.stack will
   appear.
b) If the bug is fixed by bug 653926, the Error Console shows "Security Error:
   Content at ... may not load or link to chrome:...".
Not tracking this for 7 any more. Marcia, can you get someone to verify this one? Thanks!
tracking-firefox7: + → -
Mozilla/5.0 (Windows NT 5.1; rv:9.0a1) Gecko/20110920 Firefox/9.0a1,
Mozilla/5.0 (Windows NT 5.1; rv:8.0a2) Gecko/20110921 Firefox/8.0a2,
Mozilla/5.0 (Windows NT 5.1; rv:7.0) Gecko/20100101 Firefox/7.0 (Firefox Beta 6 build)

In all 3 builds I do not get the alert dialog, but I get Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMLocation.assign]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://lss-content-test2/content/sub.js :: <TOP_LEVEL> :: line 2"  data: no] in the console. So this looks good from a verification perspective.
blocking1.9.2: .23+ → ?
status-firefox6: affected → wontfix
status-firefox7: affected → fixed
status-firefox8: affected → fixed
status-firefox9: affected → fixed

Updated

6 years ago
blocking1.9.2: ? → .24+
For 1.9.2 this should be fixed by bug 653926.
(Assignee)

Comment 10

6 years ago
See bug 653926.
status1.9.2: wanted → .24-fixed
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Depends on: 653926
Resolution: --- → FIXED
Whiteboard: [sg:critical] → [sg:critical] fixed in bug 653926
Alias: CVE-2011-3647
Whiteboard: [sg:critical] fixed in bug 653926 → [sg:critical] patch in bug 653926

Comment 11

6 years ago
Based on the above comment, does it imply that this bug is a duplicate of 653926?
But 653926 has a different CVE id?

Comment 12

6 years ago
Ah, sorry i think i missed comment #10, for 1.9.2 the issue is fixed in bug 653926
Blocks: 678924
Whiteboard: [sg:critical] patch in bug 653926 → [sg:critical][qa+] patch in bug 653926
verified on 8, 9 and 10
Status: RESOLVED → VERIFIED
Keywords: qawanted → verified-aurora, verified-beta
Whiteboard: [sg:critical][qa+] patch in bug 653926 → [sg:critical][qa!] patch in bug 653926
Group: core-security
You need to log in before you can comment on or make changes to this bug.