Last Comment Bug 474695 - "ASSERTION: Principal mismatch. Not good" at
: "ASSERTION: Principal mismatch. Not good" at
: assertion
Product: Core
Classification: Components
Component: Security (show other bugs)
: Trunk
: x86 Mac OS X
-- minor (vote)
: ---
Assigned To: Johnny Stenback (:jst,
: David Keeler [:keeler] (use needinfo?)
Depends on:
  Show dependency treegraph
Reported: 2009-01-21 14:53 PST by Jesse Ruderman
Modified: 2015-10-16 11:52 PDT (History)
10 users (show)
jst: blocking1.9.1-
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

testing principal origin equality rather than pointer equality (1010 bytes, patch)
2009-05-07 13:54 PDT, Ben Newman (:bnewman) (:benjamn)
no flags Details | Diff | Splinter Review

Description User image Jesse Ruderman 2009-01-21 14:53:05 PST
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
Comment 1 User image Jesse Ruderman 2009-04-20 17:08:20 PDT
Blake says this should be a blocker, and he or jst will try to figure it out despite the lack of a reduced testcase.
Comment 2 User image Johnny Stenback (:jst, 2009-04-23 17:14:01 PDT
Blocking, this assertion is pretty much always bad.
Comment 3 User image Johnny Stenback (:jst, 2009-05-05 13:21:43 PDT
I've been trying to reproduce this for some time now w/o any luck, anyone else able to reproduce this?
Comment 4 User image Jesse Ruderman 2009-05-05 21:56:00 PDT
I was able to reproduce this the second time I loaded the page.
Comment 5 User image Johnny Stenback (:jst, 2009-05-06 00:40:42 PDT
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.
Comment 6 User image Ben Newman (:bnewman) (:benjamn) 2009-05-06 12:28:08 PDT
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
Comment 7 User image Ben Newman (:bnewman) (:benjamn) 2009-05-07 13:54:06 PDT
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.
Comment 8 User image Johnny Stenback (:jst, 2009-05-07 14:34:58 PDT
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 User image Johnny Stenback (:jst, 2009-05-07 15:39:59 PDT
And yeah, not exploitable, unblocking.
Comment 10 User image Boris Zbarsky [:bz] (still a bit busy) 2009-05-07 18:51:35 PDT
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.
Comment 11 User image Daniel Veditz [:dveditz] 2009-05-11 13:28:20 PDT
Un-hide the bug given comment 9?
Comment 12 User image Alex Vincent [:WeirdAl] 2009-07-21 15:34:55 PDT
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.
Comment 13 User image Jesse Ruderman 2010-11-18 19:24:38 PST
WFM with the steps in comment 0.
Comment 14 User image Johnny Stenback (:jst, 2012-03-25 01:47:09 PDT
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.
Comment 15 User image Johnny Stenback (:jst, 2012-03-25 01:47:29 PDT
Fixed by bug 700561.

Note You need to log in before you can comment on or make changes to this bug.