465587 - WARNING: NS_ENSURE_TRUE(uri) failed: file /Users/markus/Programming/mmozilla/caps/src/nsScriptSecurityManager.cpp, line 140 with XUL tabbox

Status: RESOLVED INVALID

(Core :: XPConnect, defect, P3)

Description

[Markus Stange [:mstange]]

Attachment: testcase

This warning fires about 50 times whenever I switch tabs in the attached testcase.

bz said this is bad.

Comment 1

[Boris Zbarsky [:bzbarsky]]

So we're ending up in nsScriptSecurityManager::CheckObjectAccess with our subject principal the nsPrincipal for the attachment and the object having the system principal as its object principal.  Then we end up calling GetPrincipalDomainOrigin on the system principal (via nsScriptSecurityManager::CheckPropertyAccessImpl) and get this warning.

Here's the relevant stack to the CheckObjectAccess call:

#3  0x01f33841 in nsScriptSecurityManager::CheckObjectAccess (cx=0x12e5000, obj=0x30fa2e0, id=47562996, mode=JSACC_READ, vp=0xbfff9fac) at /Users/bzbarsky/mozilla/debug/mozilla/caps/src/nsScriptSecurityManager.cpp:516
#4  0x002ddb02 in js_InternalGetOrSet (cx=0x12e5000, obj=0x30fa2e0, id=47562996, fval=47812160, mode=JSACC_READ, argc=0, argv=0x0, rval=0xbfffa2e4) at jsinterp.cpp:1441
#5  0x002f3425 in js_NativeGet (cx=0x12e5000, obj=0x30fa2e0, pobj=0x2d98ca0, sprop=0x12b0170, vp=0xbfffa2e4) at /Users/bzbarsky/mozilla/debug/mozilla/js/src/jsobj.cpp:3663
#6  0x002f4285 in js_GetPropertyHelper (cx=0x12e5000, obj=0x30fa2e0, id=47562996, vp=0xbfffa2e4, entryp=0x0) at /Users/bzbarsky/mozilla/debug/mozilla/js/src/jsobj.cpp:3812
#7  0x002f4338 in js_GetProperty (cx=0x12e5000, obj=0x30fa2e0, id=47562996, vp=0xbfffa2e4) at /Users/bzbarsky/mozilla/debug/mozilla/js/src/jsobj.cpp:3824
#8  0x0025061e in JS_GetProperty (cx=0x12e5000, obj=0x30fa2e0, name=0x11b49e0 "disabled", vp=0xbfffa2e4) at /Users/bzbarsky/mozilla/debug/mozilla/js/src/jsapi.cpp:3618
#9  0x00d406fd in nsXPCWrappedJSClass::CallMethod (this=0xddd15c0, wrapper=0xdde2af0, methodIndex=113, info=0x11b49a0, nativeParams=0xbfffa494) at /Users/bzbarsky/mozilla/debug/mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp:1542
#10 0x00d38017 in nsXPCWrappedJS::CallMethod (this=0xdde2af0, methodIndex=113, info=0x11b49a0, params=0xbfffa494) at /Users/bzbarsky/mozilla/debug/mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp:563
#11 0x00521dd4 in PrepareAndDispatch (self=0xddcec00, methodIndex=113, args=0xbfffa5b4) at /Users/bzbarsky/mozilla/debug/mozilla/xpcom/reflect/xptcall/src/md/unix/xptcstubs_unixish_x86.cpp:93
#12 0x0052416f in nsXPTCStubBase::Stub113 (this=0xddcec00) at xptcstubsdef.inc:111
#13 0x03b75161 in nsXULElement::IsFocusable (this=0xbf6a7a0, aTabIndex=0xbfffa630) at /Users/bzbarsky/mozilla/debug/mozilla/content/xul/content/src/nsXULElement.cpp:568

This is the xulControl->GetDisabled() call, with xulControl implemented in the chrome XBL.

It seems odd (and not so safe) to me that there are any system-principal objects around at all, but given that there are, should calls through XBL-implemented interfaces skip the security check in question, perhaps?

Comment 2

[Boris Zbarsky [:bzbarsky]]

Oh, and the blocking request is on sorting out whether there's a security problem here.

Comment 3

[Johnny Stenback (:jst)]

Over to mrbkap and marking security sensitive until we know otherwise.

Comment 4

[Blake Kaplan (:mrbkap) (inactive)]

This isn't security sensitive. What's happening is that we're trying to find the next focusable content when we switch tabs. Because <tab> is implemented in XUL, we call into the content-privileged XUL, which calls:
  document.commandDispatcher.advanceFocusIntoSubtree(aNewTab);
This ends up in the event listener manager, which walks up the docshell chain when it realizes that it can't find anything focusable in the tabs. Then, it tries to focus something in the parent docshell (which is a chrome docshell). This ends up calling IsFocusable on an XBL-implemented property, which triggers a security check. Then, because the nearest JS code on the stack is the content-privileged tab implementation, we try to actually do a security check with the object principal being the system principal and we get this warning.

This isn't security sensitive, since we censor chrome objects in the focus controller and it isn't the *content* nodes that end up with the system principal.

Over to smaug to see if the event listener manager should really be walking from a content docshell into a chrome docshell.

Comment 5

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 24 weeks.

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

The setup has changed radically so this isn't really valid anymore.