The default bug view has changed. See this FAQ.

"ASSERTION: Principal mismatch. Not good" at




8 years ago
2 years ago


(Reporter: Jesse Ruderman, Assigned: jst)



Mac OS X
Bug Flags:
blocking1.9.1 -

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [sg:nse], URL)


(1 attachment)



8 years ago
Steps to reproduce:
1. Load by giving the URL to Firefox on the command line.


###!!! ASSERTION: Principal mismatch.  Not good: '!aAllowShortCircuit || result == doGetObjectPrincipal(origObj, PR_FALSE)', file /Users/jruderman/central/caps/src/nsScriptSecurityManager.cpp, line 2377


8 years ago
Whiteboard: [sg:investigate]

Comment 1

8 years ago
Blake says this should be a blocker, and he or jst will try to figure it out despite the lack of a reduced testcase.
Ever confirmed: true
Flags: blocking1.9.1?

Comment 2

8 years ago
Blocking, this assertion is pretty much always bad.
Assignee: nobody → jst
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P2
Target Milestone: --- → mozilla1.9.1

Comment 3

8 years ago
I've been trying to reproduce this for some time now w/o any luck, anyone else able to reproduce this?

Comment 4

8 years ago
I was able to reproduce this the second time I loaded the page.

Comment 5

8 years ago
Ben, can you give this a try and see if you see the principal mismatch exception? I tried numerous times, and I can consistently reproduce *a* assertion, but it's "###!!! ASSERTION: Adding child where we already have a child?  This will likely misbehave". So far no luck reproducing the principal mismatch assertion.
Getting it pretty consistently with firebug turned on (who knew?). Here's a stack trace:

#0  nsScriptSecurityManager::doGetObjectPrincipal (aObj=0x1e9af760, aAllowShortCircuit=1) at /Users/ben/dev/debug/caps/src/nsScriptSecurityManager.cpp:2347
#1  0x11446427 in nsScriptSecurityManager::CheckPropertyAccessImpl (this=0x756c30, aAction=1, aCallContext=0xbfffc9dc, cx=0xe4f800, aJSObject=0x1e9af760, aObj=0x1ea9fd40, aTargetURI=0x0, aClassInfo=0x1e85e0f4, aClassName=0x0, aProperty=444916220, aCachedClassPolicy=0x1ea74524) at /Users/ben/dev/debug/caps/src/nsScriptSecurityManager.cpp:701
#2  0x11446c9f in nsScriptSecurityManager::CanAccess (this=0x756c30, aAction=1, aCallContext=0xbfffc9dc, cx=0xe4f800, aJSObject=0x1e9af760, aObj=0x1ea9fd40, aClassInfo=0x1e85e0f4, aPropertyName=444916220, aPolicy=0x1ea74524) at /Users/ben/dev/debug/caps/src/nsScriptSecurityManager.cpp:3047
#3  0x11269536 in XPCWrappedNative::CallMethod (ccx=@0xbfffc9dc, mode=XPCWrappedNative::CALL_GETTER) at /Users/ben/dev/debug/js/src/xpconnect/src/xpcwrappednative.cpp:2061
#4  0x1127a473 in XPCWrappedNative::GetAttribute (ccx=@0xbfffc9dc) at xpcprivate.h:2322
#5  0x11276122 in XPC_WN_GetterSetter (cx=0xe4f800, obj=0x1e9af760, argc=0, argv=0xe753e8, vp=0xbfffcb00) at /Users/ben/dev/debug/js/src/xpconnect/src/xpcwrappednativejsops.cpp:1622
#6  0x002f59f6 in js_Invoke (cx=0xe4f800, argc=0, vp=0xe753e0, flags=2) at jsinterp.cpp:1399
#7  0x002f5ce9 in js_InternalInvoke (cx=0xe4f800, obj=0x1e9af760, fval=410023200, flags=0, argc=0, argv=0x0, rval=0xbfffd108) at jsinterp.cpp:1460
#8  0x002f5f69 in js_InternalGetOrSet (cx=0xe4f800, obj=0x1e9af760, id=444916220, fval=410023200, mode=JSACC_READ, argc=0, argv=0x0, rval=0xbfffd108) at jsinterp.cpp:1523
#9  0x0030248d in js_GetSprop (cx=0xe4f800, sprop=0x1f9b1b70, obj=0x1e9af760, vp=0xbfffd108) at jsscope.h:363
#10 0x0030deb9 in js_NativeGet (cx=0xe4f800, obj=0x1e9af760, pobj=0x1e96d0c0, sprop=0x1f9b1b70, vp=0xbfffd108) at /Users/ben/dev/debug/js/src/jsobj.cpp:4249
#11 0x0030ec91 in js_GetPropertyHelper (cx=0xe4f800, obj=0x1e9af760, id=444916220, cacheResult=1, vp=0xbfffd108) at /Users/ben/dev/debug/js/src/jsobj.cpp:4415
#12 0x002dc4f4 in js_Interpret (cx=0xe4f800) at /Users/ben/dev/debug/js/src/jsinterp.cpp:4452
#13 0x002f436a in js_Execute (cx=0xe4f800, chain=0x1ed210a0, script=0x1985f7a0, down=0x0, flags=0, result=0x0) at jsinterp.cpp:1633
#14 0x00278a45 in JS_EvaluateUCScriptForPrincipals (cx=0xe4f800, obj=0x1ed210a0, principals=0x1f0eed24, chars=0x19725e70, length=9, filename=0x19805948 "", lineno=2, rval=0x0) at /Users/ben/dev/debug/js/src/jsapi.cpp:5151
#15 0x134cbcf3 in nsJSContext::EvaluateString (this=0x1ea19d60, aScript=@0xbfffd774, aScopeObject=0x1ed210a0, aPrincipal=0x1f0eed20, aURL=0x19805948 "", aLineNo=2, aVersion=0, aRetValue=0x0, aIsUndefined=0xbfffd758) at /Users/ben/dev/debug/dom/base/nsJSEnvironment.cpp:1605
#16 0x134fb704 in nsGlobalWindow::RunTimeout (this=0x2000c390, aTimeout=0x19805990) at /Users/ben/dev/debug/dom/base/nsGlobalWindow.cpp:7761
#17 0x134fbdda in nsGlobalWindow::TimerCallback (aTimer=0x198059d0, aClosure=0x19805990) at /Users/ben/dev/debug/dom/base/nsGlobalWindow.cpp:8114
#18 0x005598cc in nsTimerImpl::Fire (this=0x198059d0) at /Users/ben/dev/debug/xpcom/threads/nsTimerImpl.cpp:427
#19 0x00559b04 in nsTimerEvent::Run (this=0x19805be0) at /Users/ben/dev/debug/xpcom/threads/nsTimerImpl.cpp:519
#20 0x00552116 in nsThread::ProcessNextEvent (this=0x714c80, mayWait=0, result=0xbfffd9b4) at /Users/ben/dev/debug/xpcom/threads/nsThread.cpp:510
#21 0x004d8b7e in NS_ProcessPendingEvents_P (thread=0x714c80, timeout=20) at nsThreadUtils.cpp:180
#22 0x11982913 in nsBaseAppShell::NativeEventCallback (this=0x7395c0) at /Users/ben/dev/debug/widget/src/xpwidgets/nsBaseAppShell.cpp:121
#23 0x119388a4 in nsAppShell::ProcessGeckoEvents (aInfo=0x7395c0) at /Users/ben/dev/debug/widget/src/cocoa/
#24 0x974745f5 in CFRunLoopRunSpecific ()
#25 0x97474cd8 in CFRunLoopRunInMode ()
#26 0x906c92c0 in RunCurrentEventLoopInMode ()
#27 0x906c90d9 in ReceiveNextEventCommon ()
#28 0x906c8f4d in BlockUntilNextEventMatchingListInMode ()
#29 0x948d4d7d in _DPSNextEvent ()
#30 0x948d4630 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#31 0x948cd66b in -[NSApplication run] ()
#32 0x1193695e in nsAppShell::Run (this=0x7395c0) at /Users/ben/dev/debug/widget/src/cocoa/
#33 0x126331ce in nsAppStartup::Run (this=0x753850) at /Users/ben/dev/debug/toolkit/components/startup/src/nsAppStartup.cpp:193
#34 0x000bc934 in XRE_main (argc=4, argv=0xbffff008, aAppData=0x70e980) at /Users/ben/dev/debug/toolkit/xre/nsAppRunner.cpp:3359
#35 0x000026e3 in main (argc=4, argv=0xbffff008) at /Users/ben/dev/debug/browser/app/nsBrowserApp.cpp:156
Created attachment 376306 [details] [diff] [review]
testing principal origin equality rather than pointer equality

index_food_create.php .writes a remote script tag into the document of its sibling frame index_food_image.php. The remote script reads document.documentElement.scrollTop, which triggers the assertion because document.documentElement has a different principal from that of its (xpcnative)wrapper. These two principals are, however, same-origin, as enforced when the wrapping originally occurred (i.e., in nsDocument::OpenCommon). Furthermore, the document.write was only permitted because the two frames had the same origin.

The assertion can be silenced by switching to nsIPrincipal::Equals instead of ==, and this change seems consistent with what nsDocument::OpenCommon actually enforces.

Unblocking because the principal mismatch isn't exploitable.
Attachment #376306 - Flags: superreview?(jst)
Attachment #376306 - Flags: review?(jst)
Priority: P2 → --
Severity: normal → minor

Comment 8

8 years ago
Boris, what do you think about this, we've got a document whose principals mutate (but stay within the same origin), which triggers this assertion. Do you think we should take bnewman's patch to fix the asserytion, or try to update the principal in the scope etc?

Comment 9

8 years ago
And yeah, not exploitable, unblocking.
Flags: blocking1.9.1+ → blocking1.9.1-
Do we still use the principal for the base URI anywhere?  If we do, then not updating the principal means base URIs will be wrong....  I've been working on removing such uses, so maybe we no longer do that.  

More generally, any time we use the principal URI for anything but a same origin compare or a scheme check, this situation could cause issues.
Un-hide the bug given comment 9?
Whiteboard: [sg:investigate] → [sg:nse]


8 years ago
Group: core-security
I'm hitting this assertion with a custom XBL binding in a XULRunner app - and the patch doesn't fix that.

I'm attending OSCON this week, and I'll be happy to show the assertion failure to anyone interested.
Flags: wanted1.9.2?
Target Milestone: mozilla1.9.1 → ---

Comment 13

6 years ago
WFM with the steps in comment 0.
Flags: wanted1.9.2?

Comment 14

5 years ago
Comment on attachment 376306 [details] [diff] [review]
testing principal origin equality rather than pointer equality

Clearing forgotten reviews, this was just recently fixed in bug 700561.
Attachment #376306 - Flags: superreview?(jst)
Attachment #376306 - Flags: review?(jst)

Comment 15

5 years ago
Fixed by bug 700561.
Last Resolved: 5 years ago
Resolution: --- → FIXED
Keywords: testcase-wanted
You need to log in before you can comment on or make changes to this bug.