474695 - "ASSERTION: Principal mismatch. Not good" at caloriesperhour.com

Status: RESOLVED FIXED

(Core :: Security, defect)

Description

[Jesse Ruderman]

Steps to reproduce:
1. Load http://www.caloriesperhour.com/index_food.php by giving the URL to Firefox on the command line.

Result:

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

Comment 1

[Jesse Ruderman]

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

[Johnny Stenback (:jst)]

Blocking, this assertion is pretty much always bad.

Comment 3

[Johnny Stenback (:jst)]

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

Comment 4

[Jesse Ruderman]

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

Comment 5

[Johnny Stenback (:jst)]

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

[Ben Newman (:bnewman) (:benjamn)]

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 "http://images.intellitxt.com/ast/js/vm/func_200904241650.js", 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 "http://images.intellitxt.com/ast/js/vm/func_200904241650.js", 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/nsAppShell.mm:412
#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/nsAppShell.mm:727
#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

[Ben Newman (:bnewman) (:benjamn)]

Attachment: 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

[Johnny Stenback (:jst)]

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

[Johnny Stenback (:jst)]

And yeah, not exploitable, unblocking.

Comment 10

[Boris Zbarsky [:bzbarsky]]

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

[Daniel Veditz [:dveditz]]

Un-hide the bug given comment 9?

Comment 12

[Alex Vincent [:WeirdAl]]

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

[Jesse Ruderman]

WFM with the steps in comment 0.

Comment 14

[Johnny Stenback (:jst)]

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

[Johnny Stenback (:jst)]

Fixed by bug 700561.