400771 - window.eval() not callable through NPRuntime.

Status: RESOLVED WONTFIX

(Core Graveyard :: Plug-ins, defect, P3)

Description

[Johnny Stenback (:jst)]

Given the somewhat recent changes to make eval stricter in its checking for how it's being called, eval() is now no longer callable by a plugin through NPRuntime. There's a comming in obj_eval() that says:

         * NB: This means that native callers (who reach this point through
         * the C API) must use the two parameter form.

but even when using the two parameter form, there's no scripted caller, so we won't find a caller principal, which makes js_CheckPrincipalsAccess() throw an exception and fail.

Short of wrapping this call (or all calls) coming from plugins in a scripted caller I don't really see a good way around this.

Brendan, Blake, any thoughts on this?

Comment 1

[Brendan Eich [:brendan]]

We could trust the no-scripted-caller case, and patch anything that does that that is insecure given such trust. Blake?

/be

Comment 2

[georgi - hopefully not receiving bugspam]

i am not sure i understand this in detatils.

on today trunk:
data:text/html;,<img%20src="javascript:alert(1)">

* Call to xpconnect wrapped JSObject produced this error:  *
[Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMLocation.host]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://browser/content/browser.js :: browser_onSecChange :: line 3475"  data: no]
************************************************************
WARNING: No principal to execute JS with: file firefox-cvs/mozilla/dom/src/jsurl/nsJSProtocolHandler.cpp, line 175

Comment 3

[Johnny Stenback (:jst)]

G30rgi, I'm not sure how that comment applies to this bug?

Comment 4

[georgi - hopefully not receiving bugspam]

(In reply to comment #3)
> G30rgi, I'm not sure how that comment applies to this bug?
> 

Just pointing out that "no principal" codepath can be hit via data URI (probably another regression) - comment #2 seems to trust this case. may be wrong.

Comment 5

[Blake Kaplan (:mrbkap) (inactive)]

(In reply to comment #1)
> We could trust the no-scripted-caller case, and patch anything that does that
> that is insecure given such trust. Blake?

This broke because of bug 311403 (see also bug 311455). Ideally, with what we're now calling centralized security checks (via wrappers), we could remove this code and just trust the principal of the eval function (without doing any sort of belt-and-braces check a la JS_EvalFramePrincipals). Note that the vectors attacked in the cited bugs no longer work due to bug 382509 removing m.init.eval and bug 300079 make accessing chrome-privileged functions much harder, so this might not be as scary as I think.

Comment 6

[BMO Automation]

Resolving as wont fix, plugin support deprecated in Firefox 85.