716262 - Components.stack looses stacks of function has dipatchEvent via iframe.src

Status: RESOLVED INACTIVE

(Core :: XPConnect, defect)

Description

[teramako]

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0a1) Gecko/20120106 Firefox/12.0a1
Build ID: 20120106081835

Steps to reproduce:

on Greasemonkey, some GM_* apis validate either the api is called from the contents or not using Components.stack.
This validator is GM_apiLeakCheck [1] .

In many case, this validator works good.
But in some case I noticed, does'nt work because the stack doesn't appear in Components.stack.

A test code and Componets.stack results are here [2];

UserScript:

* addEventListener and call GM_* apis in the callback function

PageContent:

* define function sendEvent
  * createEvent and dispatchEvent
* create iframe and set src 'javascript:window.top.sendEvent()'


[1]: https://github.com/greasemonkey/greasemonkey/blob/master/components/greasemonkey.js#L51
[2]: https://gist.github.com/1565506

Comment 1

[teramako]

Additionally I reported to Greasemonkey.
https://github.com/greasemonkey/greasemonkey/issues/1494

Comment 2

[Anthony Lieuallen]

Confirmed; mostly-just-clickable steps recorded in GM's issue.

I have to think about it a little bit, but this could be anywhere from helpful to benign to a dangerous security hole, for Greasemonkey.  Re-worded explanation:

When Greasemonkey sees a call to one of its privileged APIs, it examines Components.stack to see where the call is coming from.  If _any_ part of the stack trace comes from anything but three well defined locations (parts of Greasemonkey itself) by "stack.filename" prefix, we abort the call.  This works because the GM scripts themselves are attributed to the point where we evalInSandbox() them.

In this bug, teramako is reporting a way to completely bypass this: the content window (about:blank or javascript:... nor the http:... page executing the ".src=") location is nowhere within the trace.  Regardless of the fact that the same sendEvent() function is doing the work, and the stack is as expected when being called directly.

Comment 3

[Anthony Lieuallen]

(Oh, and FWIW, confirmed on:

Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0) Gecko/20100101 Firefox/10.0

)

Comment 4

[janekptacijarabaci]

Confirmed on:

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20130729 Firefox/25.0

Comment 5

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.