462717 - Schema Include - Security Error: Content at moz-nullprincipal

Status: RESOLVED DUPLICATE of bug 490983

(Core Graveyard :: XForms, defect)

Description

[Albert Holtsclaw]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3
Build Identifier: Firefox 3.0.3 / XForms Plug-in 0.8.6ff3

Using xs:include statements in schema files (on the local machine) with the 0.8.6ff3 plug-in with Firefox 3 causes the following error:

"Security Error: Content at moz-nullprincipal:{49ac5b1a-fcd4-40f2-88a6-adf5c601d459} may not load data from file: ..."   [file names removed]

Taken from our conversation on mozilla.dev.tech.xforms:

"The bug is due to the patch checked in for
https://bugzilla.mozilla.org/show_bug.cgi?id=416534.  When
nsSchemaLoader calls basePrincipal::CheckMayLoad, it only returns errors
because the principal is actually a nsNullPrincipal.  So either
CheckMayLoad needs to be able to handle local files or we need some more
logic.  I'm waiting to hear back from the patch author to see what the
best fix is for our situation.

Please open a bug on us, xforms, attaching a very simplified testcase
(i.e. an xform with one control, including a local schema file which
xs:includes another local schema file) that re-creates the problem and
we'll work with mozilla to try to figure out how to best fix the issue.

Thanks,
--Aaron "

Reproducible: Always

Comment 1

[Albert Holtsclaw]

Attachment: Test Case

Comment 2

[aaronr]

Got some feedback from Jonas:

"Documents loaded using the chrome principal are given the null principal 
for security reasons. This prevents such documents from executing 
scripts etc with chrome privilege.

This was a change we made in FF3, so it's likely what you're running in to."

Waiting for feedback from him as to what we need to do to fix this problem.

Comment 3

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I thought I had replied, but maybe not. Is there a reason you're not simply using the principal of the loading page? That seems more secure too

Comment 4

[aaronr]

(In reply to comment #3)
> I thought I had replied, but maybe not. Is there a reason you're not simply
> using the principal of the loading page? That seems more secure too

You had replied with that question, but not to my reply of your reply :-)

We came up with using the system principal after reading the discussions in bug 392322.  Also thought that we'd need to use the system principal since we have no idea what remote schema might be getting pulled in from the user's schema (for example, could be a schema from another xml-based standard like Open Office).  According to comments around the change, we thought at the time that using the system principal was ok because the actual load goes through XMLHttpRequest so no executable code will run and that you can't really get to schema contents from JS (line 815 in mozilla/extensions/xforms/nsXFormsModelElement.cpp).

We can use the document's principal if you think that is the right answer and won't handcuff us as to what remote schemas we can load.

Comment 5

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Using remote schemas would not work if you simply used the page principal, no.

Though using remote schemas scare me a little as any cross-site data retrieval can be sensitive.

I suspect what you'll have to do is to use the chrome principal to do the loading, but then modify the principal of the returned document to one that will allow further loads. If those further loads are also cross-site then I guess you'll have to set the chrome principal.

Alternatively, we could expose a flag that lets you do cross-site loads without forcing you to use the chrome principal. This does not exist yet though, but should be trivial to implement since such a flag already exists internally.

Bz: any other suggestions?

Comment 6

[Boris Zbarsky [:bzbarsky]]

So there's no way that the linking page can extract any information out of the schema?

Comment 7

[aaronr]

(In reply to comment #6)
> So there's no way that the linking page can extract any information out of the
> schema?

cc'ing Doron to see if he knows a way.  I don't see where we expose any of the model's loaded schema information through the .idl's.  Of course, the schema url is an attribute on the xf:model element so I guess the script could try to load the schema using a straight xmlhttprequest after querying the attribute value or try loading the url with nsSchemaLoader::LoadAsync (which is exposed through .idl) which uses the security manager's subject principal.

Comment 8

[Boris Zbarsky [:bzbarsky]]

That's not relevant, since at that point there will be a separate security check.

The real question is whether the page can detect anything about the schema.  It doesn't have to be exposed in IDL.  For example, does the schema affect what's submitted to the server?  Can the page that links to the schema use that to gather information about the schema file?

Comment 9

[aaronr]

Schema affects whether a submission can happen.  If any of the instance data to be submitted is invalid, submission will fail.  But the submission doesn't serialize any of the schema information, only what is already in the instance document which the page already has full access to through the standard XForms interface.

The page can find out what the schema type is for an instance node and from that can find the list of types that the particular type derives from.  But apart from that, nothing else about the structure or contents of the schema.  At least I can't think of anything else.  Doron?

Comment 10

[Doron Rosenberg (IBM)]

You face the same concerns as allowing css from different domains.  Actually, probably less so.

You can't access the loaded schema and have it do something like load another file.

The schema is kept separate from xforms and an xform can't query anything out of the schema, not even JS can do that.

So should be safe.

Comment 11

[Boris Zbarsky [:bzbarsky]]

> You face the same concerns as allowing css from different domains.

If we could enforce same-origin restrictions (modulo access controls) there, we would.  But that cat is out of the bag for too long.  Luckily, sites know about that.  I don't know how many of them know to lock up their random XML files (which could be treated as schemas by this code)...

Comment 12

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I'm no big fan of the cross-site CSS loading either. The main reason we allow that is because not doing so would break the web. So that's not a very strong argument for allowing cross-site schemas.

Can you mine data out of a schema by creating minimal minimal DOM trees and see if they validate or not? Or would you basically have to create an infinite amount of trees to do so?

Comment 13

[aaronr]

I don't know that you could learn much about the schema just from figuring out whether node values validate or not.  Because you wouldn't know why something didn't validate.  You just would know that it didn't validate.  Now it is possible that you MIGHT get some hint at the schema's structure by using the interface and getting the chain of inherited types for the data node.  But to get the most information you'd have to know the deepest type so that you could specify it on the node.  But I don't know how you'd get the deepest type without already knowing the structure of the schema.  You could guess at type names, but even if you get one right, you just have a list of type names.  You know nothing about the type apart from its name and from that I guess you could get whether it was complex or simple.  I don't see that we expose any more information than that.

Comment 14

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I'm ok with allowing cross site schema load for now, though if we ever were to consider including XForms support natively it's something we'd have to review in more detail and might end up changing.

So with that I think the way to go is either adding the ability to set the cross-origin load flag, setting the principal of the schema document after it has been loaded, or simply letting the XForms code ignore the principal of the schema document. I suspect the latter is what you'll want to do actually.

Comment 15

[Philipp Wagner [:imphil]]

Attachment: use system principal for xsd:include/xsd:import, too.

This patch makes xsd:include and xsd:import use the system principal for loading schemas. This is the same as it is when loading the initial schema from XForms, so the same possible security problems here, which are according to comment #14 ok.

The attached testcase has some problems, so I created a own one at
http://philipp.wagner.name/temp/xforms-schema-xsd_include/form.xhtml

I was not able to test nsSchemaLoader::Load(), but as nobody seems to have noticed that it is not working since Gecko 1.9 I guess it's not really used by anybody.

Comment 16

[aaronr]

Comment on attachment 374673 [details] [diff] [review]
use system principal for xsd:include/xsd:import, too.

I don't see any coding errors.  But get signoff from Doron since he knows more about schema and security than I do.

Comment 17

[Philipp Wagner [:imphil]]

Comment on attachment 374673 [details] [diff] [review]
use system principal for xsd:include/xsd:import, too.

please do not commit this patch, it contains a possible security problem. Please see bug #490983 comment 3 for details.

Comment 18

[aaronr]

(In reply to comment #17)
> (From update of attachment 374673 [details] [diff] [review])
> please do not commit this patch, it contains a possible security problem.
> Please see bug #490983 comment 3 for details.

So should we close this bug?  Or do you have another patch coming?  Sorry I didn't already commit it.  Forgot all about it.

Comment 19

[Philipp Wagner [:imphil]]

The patch in bug #490983 resolves this issue, too.