622483 - ASSERTION: Principal mismatch. Not good: 'strcmp(jsClass->name, "Location") == 0 ? NS_SUCCEEDED(CheckSameOriginPrincipal(result, principal)) : result == principal',

Status: RESOLVED WORKSFORME

(Core :: Security: CAPS, defect)

Description

[Alex Miller]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13
Build Identifier: 

Got this assertion with cross_fuzz when the seed was #1243054328. Marking as security sensitive because of bug 474695 comment 2. Also, based on the satisfied condition it seems possible to bypass the same-origin policy.

Reproducible: Always

Steps to Reproduce:
1. Load cross_fuzz (seeded) with a seed of #1243054328.
2. Dig through a boatload of assertions until you get that assertion.

Comment 1

[Bob Clary [:bc] (inactive)]

See also bug 474695 for a possible dupe and analysis.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Also see bug 616913.  If you can reproduce this, can you examine the class name when you hit the assert?  For that matter, can you examine the principals involved?

Comment 3

[Alex Miller]

(In reply to comment #2)
> Also see bug 616913.  If you can reproduce this, can you examine the class name
> when you hit the assert?  For that matter, can you examine the principals
> involved?

I don't have access to that bug, attaching the stack trace soon

Comment 4

[Alex Miller]

Attachment: Stack trace

Comment 5

[Boris Zbarsky [:bzbarsky]]

I didn't ask for the stack trace, right?  I asked what jsClass->name is in your case.

Comment 6

[Alex Miller]

(In reply to comment #5)
> I didn't ask for the stack trace, right?  I asked what jsClass->name is in your
> case.

How exactly would I go about finding the classname?

Comment 7

[Boris Zbarsky [:bzbarsky]]

Well, you have this in a debugger, right?  Just examine the relevant member of that object.  How to do that depends on your debugger.

Comment 8

[Alex Miller]

(In reply to comment #7)
> Well, you have this in a debugger, right?  Just examine the relevant member of
> that object.  How to do that depends on your debugger.

The object in which the assertion occurs? I'm not familiar with CAPS at all, nor am I familiar with any code in this area, or most computer science/OOP terms. 

nsScriptSecurityManager?

Comment 9

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

(In reply to comment #6)
> (In reply to comment #5)
> > I didn't ask for the stack trace, right?  I asked what jsClass->name is in your
> > case.
> 
> How exactly would I go about finding the classname?

Try:

(gdb) p jsClass->name

or:

(gdb) x jsClass->name

when the assertion is trapped in gdb, for example.

Comment 10

[Alex Miller]

Can I get access to bug 623189?

Comment 11

[Andreas Gal :gal]

comment 10: done

Comment 12

[Boris Zbarsky [:bzbarsky]]

For what it's worth, I was about to reply that you don't need that access to answer the questions in this bug.  I still think you don't.

Comment 13

[Alex Miller]

Gary: jsClass->name is HTMLLabelElement and "result" is 32 NULLs

Comment 14

[Boris Zbarsky [:bzbarsky]]

OK, for HTMLLabelElement this sounds ... bad (and in particular, not at all like bug 616913).  Blake?

Also, can you examine the principals?  32 nulls sounds wrong for a principal (hell, the vtable pointer should be non-null), but let's start with basics: what are the concrete types?

Comment 15

[Alex Miller]

(In reply to comment #14)
> OK, for HTMLLabelElement this sounds ... bad (and in particular, not at all
> like bug 616913).  Blake?
> 
> Also, can you examine the principals?  32 nulls sounds wrong for a principal
> (hell, the vtable pointer should be non-null), but let's start with basics:
> what are the concrete types?

According to gdb there was never a symbol by the name "principal", which seems completely wong because of the comparison before asserting, unless principal is being used uninitialized, which is a different problem.

Comment 16

[Alex Miller]

(In reply to comment #14)
> OK, for HTMLLabelElement this sounds ... bad (and in particular, not at all
> like bug 616913).  Blake?
> 
> Also, can you examine the principals?  32 nulls sounds wrong for a principal
> (hell, the vtable pointer should be non-null), but let's start with basics:
> what are the concrete types?

Can I get access to bug 616913?

Comment 17

[Alex Miller]

Fwiw, the jsClass->name is always overwritten with HTML<something>Element, not necessary Label

Comment 18

[Boris Zbarsky [:bzbarsky]]

> According to gdb there was never a symbol by the name "principal"

That's .... odd.  This is a debug non-optimized build, right?

Comment 19

[Alex Miller]

(In reply to comment #18)
> > According to gdb there was never a symbol by the name "principal"
> 
> That's .... odd.  This is a debug non-optimized build, right?

Yes

Comment 20

[Bob Clary [:bc] (inactive)]

Crash Automation hit this url from the daily crash reports.

On Nightly Mac, Linux and Windows. I was able to hit this manually locally on Mac probably 3/4 times.

Assertion failure: principals == JS_GetCompartmentPrincipals((js::GetContextCompartment(cx))), at /work/mozilla/builds/nightly/mozilla/caps/src/nsScriptSecurityManager.cpp:171

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
PushPrincipalCallback (cx=0x117926610, principals=0x119a51488) at /work/mozilla/builds/nightly/mozilla/caps/src/nsScriptSecurityManager.cpp:170

$1 = (class JSPrincipals *) 0x119a51488
(gdb) p JS_GetCompartmentPrincipals((js::GetContextCompartment(cx)))
$2 = (class JSPrincipals *) 0x11805b5c8


On Beta both Crash Automation (reproduced locally 1/4 times) ABORT: You can't dereference a NULL nsCOMPtr with operator->().: 'mRawPtr != 0'

NS_DebugBreak_P | nsCOMPtr<nsPIDOMWindow>::operator->() | mozilla::dom::Navigator::GetMozBattery(nsIDOMMozBatteryManager**) NS_InvokeByIndex_P CallMethodHelper::Invoke() CallMethodHelper::Call() XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode)

I was able to reproduce the ABORT on Aurora/Mac on shutdown after repeatedly focusing the cross fuzz tab.

Comment 21

[Bobby Holley (:bholley)]

This assertion doesn't exist anymore.