security of Javascript Global Property implementations
johnjbarton
One part of that might involve moving the Firebug command line and
window.console into a Javascript Global Property. (I think this is what
Boris was suggesting some time ago anyway).
The current implementation is very involved primarily because of
security. We inject HTML elements and scripts to create a pair of string
queues so the page can post to the Console and Firebug can post to
in-page eval for the command line. This code was a huge pain to develop
and it caused us lots of headaches, but we've solved almost all of the
problems over the last couple of years so I am reluctant to change
unless we really have a better solution.
The Javascript Global Property solves one smaller problem, how to know
when to add the 'console' (we currently have to breakpoint the first JS
script to inject our goop). My questions involve what other problems
this approach may solve, perhaps as a side effect of security
improvements since we last investigated.
Is it safe to add a Global Property, given that the code that runs is
compiled in a component scope?
Is it safe to move the values obtained from code that runs from a web
page into a component into an extension?
If not, is it safe to run postMessage() in code compiled in component
scope?
Can we safely call a function compiled in a web page, assuming that we
provide the definition of the function as a string?
Any other suggestions are welcome of course.
jjb
Boris Zbarsky
> The Javascript Global Property solves one smaller problem, how to know
> when to add the 'console' (we currently have to breakpoint the first JS
> script to inject our goop).
Note that on m-c once bug 549539 you'll just be able to look for the
relevant observer service notification and add properties as desired.
> Is it safe to add a Global Property, given that the code that runs is
> compiled in a component scope?
Not sure what you're asking. If you just add things directly via
setting window.foo then on trunk this is safe due to wrappers. If you
mean a category-defined global property that gets automagically added by
DOM code, then you should check with blake.
> Is it safe to move the values obtained from code that runs from a web
> page into a component into an extension?
Safe in the sense that getting properties off of them won't directly
exploit you, yes. It ma not be safe to do certain other things with
them (eval, pass to things that might eval, parse for commands, etc).
> If not, is it safe to run postMessage() in code compiled in component
> scope?
Should be fine, yes.
> Can we safely call a function compiled in a web page, assuming that we
> provide the definition of the function as a string?
Not sure what you're asking.
-Boris
John J Barton
I need to execute the equivalent of
__result = eval(string_expr);
in a window scope as close as possible to the web page's own code, but
where string_expr comes from chrome. I'd like to do this by code that is
equivalent to:
function __myFnc() {
debugger;
}
compiled in the web page can called from chrome. That would allow us to
concentrate all of the security analysis into the same code we have for
command line analysis when we hit breakpoints.
Is that clearer?
jjb
>
> -Boris
Boris Zbarsky
> I need to execute the equivalent of
> __result = eval(string_expr);
> in a window scope as close as possible to the web page's own code, but
> where string_expr comes from chrome. I'd like to do this by code that is
> equivalent to:
> function __myFnc() {
> debugger;
> }
> compiled in the web page can called from chrome.
So you want to set up a function which has the principal of the web page
(and whose body is determined by you). That should be doable. Then you
want to call it from chrome? This is safe in the sense that you don't
get exploited. The function itself will do the eval, so that should be
happening with the web page's permisions, so safe.
-Boris
johnjbarton
Hmmm. I can call the function, but jsd never triggers onDebugger():
var scriptToEval = "this.__firebugHalter = function(){debugger;};"
// (jsd && jsd.isOn && (jsd.pauseDepth == 0) ) is true here
win.wrappedJSObject.__firebugHalter();
I checked that the function is called and executes.
Any chance that the security mechanism is preventing jsd?
jjb
johnjbarton
...
> The Javascript Global Property solves one smaller problem, how to know
> when to add the 'console'
As far as I can tell now this was a dead end: the Javascript Global
Property requires IDL and IDL can't express Javascript's variable number
of arguments. So we can't implement the Firebug console API in XPCOM IDL. eg
console.log(object<, object, ...>)
jjb
Dave Townsend
You could do it if your component was C++. Alternatively you can use the
[optional] flag to mark arguments as optional. You'd still have to have
an upper limit on how many there could be but the following would allow
something to pass up to 10 arguments, the limit is of course up to
however many you add to the IDL:
void log([optional] in nsIVariant arg0,
[optional] in nsIVariant arg1,
[optional] in nsIVariant arg2,
[optional] in nsIVariant arg3,
[optional] in nsIVariant arg4,
[optional] in nsIVariant arg5,
[optional] in nsIVariant arg6,
[optional] in nsIVariant arg7,
[optional] in nsIVariant arg8,
[optional] in nsIVariant arg9);
johnjbarton
Excellent thanks. Just a small FYI, on the JS side any arguments not
supplied come in as "null". That is, the JS |arguments| will have length
10 and you can't distinguish undefined from |null| values.
jjb
johnjbarton
> On 3/10/10 12:24 PM, johnjbarton wrote:
>> The Javascript Global Property solves one smaller problem, how to know
>> when to add the 'console' (we currently have to breakpoint the first JS
>> script to inject our goop).
>
> Note that on m-c once bug 549539 you'll just be able to look for the
> relevant observer service notification and add properties as desired.
And going forward additions of properties referencing chrome-created
objects with chrome-created functions will be safe? (I guess they will
run with the content principal).
>
>> Is it safe to add a Global Property, given that the code that runs is
>> compiled in a component scope?
>
> Not sure what you're asking. If you just add things directly via setting
> window.foo then on trunk this is safe due to wrappers. If you mean a
> category-defined global property that gets automagically added by DOM
> code, then you should check with blake.
Apparently blake is ahead of us. With
var console = new ConsoleGlobalProperty.CagedConsole();
console.QueryInterface(iid);
return console
from my createInstance I get
"Permission denied for <file://> to create wrapper for object of class
ConsoleGlobalProperty
So I'm uncertain how to implement a Javascript Global property in JS.
Are there examples?
jjb
Jonas Sicking
> On 3/10/2010 9:44 AM, Boris Zbarsky wrote:
>> On 3/10/10 12:24 PM, johnjbarton wrote:
>>> The Javascript Global Property solves one smaller problem, how to know
>>> when to add the 'console' (we currently have to breakpoint the first JS
>>> script to inject our goop).
>>
>> Note that on m-c once bug 549539 you'll just be able to look for the
>> relevant observer service notification and add properties as desired.
>
> And going forward additions of properties referencing chrome-created
> objects with chrome-created functions will be safe?
Yes. Though not *yet* on all branches. We'll be backporting this to
older branches, but that hasn't happened yet.
> (I guess they will
> run with the content principal).
No, they will be run with chrome privileges.
>>> Is it safe to add a Global Property, given that the code that runs is
>>> compiled in a component scope?
>>
>> Not sure what you're asking. If you just add things directly via setting
>> window.foo then on trunk this is safe due to wrappers. If you mean a
>> category-defined global property that gets automagically added by DOM
>> code, then you should check with blake.
>
> Apparently blake is ahead of us. With
> var console = new ConsoleGlobalProperty.CagedConsole();
> console.QueryInterface(iid);
> return console
> from my createInstance I get
>
> "Permission denied for <file://> to create wrapper for object of class
> ConsoleGlobalProperty
>
> So I'm uncertain how to implement a Javascript Global property in JS.
> Are there examples?
When adding properties through the category-defined global property
mechanism, you need to implement nsIClassInfo appropriately as to allow
the web page to access the returned object. That works as it always has
when implementing XPCOM objects in javascript.
However a simpler mechanism is to just listen to the notification
mentioned in this thread and do:
newWindow.wrappedJSObject.myNewSpiffyProperty = {
foo: 42;
bar: function(x, y, z) {
... do stuff with x y and z ...
}
};
where 'newWindow' is the window object handed to you in the notification.
Hope that makes sense. Again this is only safe on trunk currently. Not
yet on any branches.
/ Jonas
johnjbarton
> On 3/16/2010 18:13, johnjbarton wrote:
>> On 3/10/2010 9:44 AM, Boris Zbarsky wrote:
>>> On 3/10/10 12:24 PM, johnjbarton wrote:
>>>> The Javascript Global Property solves one smaller problem, how to know
>>>> when to add the 'console' (we currently have to breakpoint the first JS
>>>> script to inject our goop).
>>>
>>> Note that on m-c once bug 549539 you'll just be able to look for the
>>> relevant observer service notification and add properties as desired.
>>
>> And going forward additions of properties referencing chrome-created
>> objects with chrome-created functions will be safe?
>
> Yes. Though not *yet* on all branches. We'll be backporting this to
> older branches, but that hasn't happened yet.
>
>> (I guess they will
>> run with the content principal).
>
> No, they will be run with chrome privileges.
Then there are some kind of limitations on what the content JS can do to
the objects? For example, I imagine that my chrome-created object could
have properties that affect my chrome-created functions. Bad content
code could alter those properties and exploit my chrome-created code
that runs with chrome privileges?
>
>>>> Is it safe to add a Global Property, given that the code that runs is
>>>> compiled in a component scope?
>>>
>>> Not sure what you're asking. If you just add things directly via setting
>>> window.foo then on trunk this is safe due to wrappers. If you mean a
>>> category-defined global property that gets automagically added by DOM
>>> code, then you should check with blake.
>>
>> Apparently blake is ahead of us. With
>> var console = new ConsoleGlobalProperty.CagedConsole();
>> console.QueryInterface(iid);
>> return console
>> from my createInstance I get
>>
>> "Permission denied for <file://> to create wrapper for object of class
>> ConsoleGlobalProperty
>>
>> So I'm uncertain how to implement a Javascript Global property in JS.
>> Are there examples?
>
> When adding properties through the category-defined global property
> mechanism, you need to implement nsIClassInfo appropriately as to allow
> the web page to access the returned object. That works as it always has
> when implementing XPCOM objects in javascript.
Any hints on what "appropriately" means in this case? (I implemented
nsIClassInfo already).
>
> However a simpler mechanism is to just listen to the notification
> mentioned in this thread and do:
>
And we don't have to worry about chrome objects we close over?
var securitySensitiveService = ....
> newWindow.wrappedJSObject.myNewSpiffyProperty = {
> foo: 42;
> bar: function(x, y, z) {
> ... do stuff with x y and z ...
...do stuff with securitySensitiveService ...
Jonas Sicking
> On 3/16/2010 7:45 PM, Jonas Sicking wrote:
>> On 3/16/2010 18:13, johnjbarton wrote:
>>> On 3/10/2010 9:44 AM, Boris Zbarsky wrote:
>>>> On 3/10/10 12:24 PM, johnjbarton wrote:
>>>>> The Javascript Global Property solves one smaller problem, how to know
>>>>> when to add the 'console' (we currently have to breakpoint the
>>>>> first JS
>>>>> script to inject our goop).
>>>>
>>>> Note that on m-c once bug 549539 you'll just be able to look for the
>>>> relevant observer service notification and add properties as desired.
>>>
>>> And going forward additions of properties referencing chrome-created
>>> objects with chrome-created functions will be safe?
>>
>> Yes. Though not *yet* on all branches. We'll be backporting this to
>> older branches, but that hasn't happened yet.
>>
>>> (I guess they will
>>> run with the content principal).
>>
>> No, they will be run with chrome privileges.
>
> Then there are some kind of limitations on what the content JS can do to
> the objects? For example, I imagine that my chrome-created object could
> have properties that affect my chrome-created functions. Bad content
> code could alter those properties and exploit my chrome-created code
> that runs with chrome privileges?
There by default isn't right now. What you can do is to set a magic
__exposedProps__ property which controls which properties are readable
and writable. So for example
newWindow.wrappedJSObject.myNewSpiffyProperty = {
foo: 42,
baz: 14,
bar: function(x, y, z) {
... do stuff with x y and z ...
},
__exposedProps__: { bar: 'r', baz: 'rw' }
};
In this case only the 'bar' and 'baz' properties are visible to content.
Any other property is invisible. Attempting to set .foo will throw.
Attempting to set 'bar' will also throw. Calling 'bar' will work great
(and bar will run with chrome privileges). Attempting to set 'baz' will
work great.
Currently __exposedProps__ defaults to making all properties read/write.
We discussed this and will change this so that all properties are by
default completely untouchable. I.e. can't be read or written to. Follow
progress on changing the default here:
https://bugzilla.mozilla.org/show_bug.cgi?id=553102
There's also some great docs here:
https://wiki.mozilla.org/XPConnect_Chrome_Object_Wrappers
However given that all of this stuff is still in the process of being
implemented, please be aware than not everything is going to be 100%
correct yet.
>>>>> Is it safe to add a Global Property, given that the code that runs is
>>>>> compiled in a component scope?
>>>>
>>>> Not sure what you're asking. If you just add things directly via
>>>> setting
>>>> window.foo then on trunk this is safe due to wrappers. If you mean a
>>>> category-defined global property that gets automagically added by DOM
>>>> code, then you should check with blake.
>>>
>>> Apparently blake is ahead of us. With
>>> var console = new ConsoleGlobalProperty.CagedConsole();
>>> console.QueryInterface(iid);
>>> return console
>>> from my createInstance I get
>>>
>>> "Permission denied for <file://> to create wrapper for object of class
>>> ConsoleGlobalProperty
>>>
>>> So I'm uncertain how to implement a Javascript Global property in JS.
>>> Are there examples?
>>
>> When adding properties through the category-defined global property
>> mechanism, you need to implement nsIClassInfo appropriately as to allow
>> the web page to access the returned object. That works as it always has
>> when implementing XPCOM objects in javascript.
>
> Any hints on what "appropriately" means in this case? (I implemented
> nsIClassInfo already).
I'll leave it to others to answer this. But I will note that there are
some docs for nsIClassInfo in devmo.
>> However a simpler mechanism is to just listen to the notification
>> mentioned in this thread and do:
>>
>
> And we don't have to worry about chrome objects we close over?
>
> var securitySensitiveService = ....
>
>> newWindow.wrappedJSObject.myNewSpiffyProperty = {
>> foo: 42;
>> bar: function(x, y, z) {
>> ... do stuff with x y and z ...
> ...do stuff with securitySensitiveService ...
>> }
>> };
Given that properties in closures are *always* invisible, even when no
chrome code, wrappers, or anything else special is involved, you won't
have to worry about the closure here either. Nothing special as far as
that goes.
If you're also wondering if __parent__ or __proto__ could leak
information then the answer is no here too. The wrappers involved here
protect you.
/ Jonas
Neil
> What you can do is to set a magic __exposedProps__ property which
> controls which properties are readable and writable.
Sounds as if this could be useful for bug 474698.
--
Warning: May contain traces of nuts.
Boris Zbarsky
>> When adding properties through the category-defined global property
>> mechanism, you need to implement nsIClassInfo appropriately as to allow
>> the web page to access the returned object. That works as it always has
>> when implementing XPCOM objects in javascript.
>
> Any hints on what "appropriately" means in this case? (I implemented
> nsIClassInfo already).
Does it have the DOM_OBJECT flag set?
-Boris
John J Barton
> On 3/16/2010 18:13, johnjbarton wrote:
> However a simpler mechanism is to just listen to the notification
> mentioned in this thread and do:
>
> newWindow.wrappedJSObject.myNewSpiffyProperty = {
> foo: 42;
> bar: function(x, y, z) {
> ... do stuff with x y and z ...
> }
> };
>
> where 'newWindow' is the window object handed to you in the notification.
>
> Hope that makes sense. Again this is only safe on trunk currently. Not
> yet on any branches.
On FF 3.7a3 I tried in chrome scope for |win| being a web page:
win.wrappedJSObject._firebugConsoleWindow = window;
then in code of the Web page:
window._firebugConsoleWindow.postMessage(methodName, "*");
But I fail with
Permission denied for <http://getfirebug.com> to call method
ChromeWindow.postMessage on <>.
http://getfirebug.com/tests/content/console/api/log.html
Line 44
So I'm unsure how to postMessage back to chrome.
jjb
>
> / Jonas
John J Barton
I tried another combo, adding an message listener in chrome scope:
win.addEventListener('message', this.boundMessageHandler, false);
then having the Web page talk to itself:
window.postMessage(methodName, "*");
This works, but its seriously clunky since the Firebug console has to
all postMessage on the Web page and try to figure out what is addressed
to it.
Is that our best shot?
>
> jjb
>
>>
>> / Jonas
Boris Zbarsky
> window._firebugConsoleWindow.postMessage(methodName, "*");
>
> But I fail with
>
> Permission denied for <http://getfirebug.com> to call method
> ChromeWindow.postMessage on <>.
> http://getfirebug.com/tests/content/console/api/log.html
> Line 44
Non-quickstubbed XPConnect property access and method calls do security
checks in addition to the ones performed by the security wrappers.
That said, it's a little odd to me that in this case the subject
principal when making the call on the chrome object is not forced to
system by the COW. Blake, is that the expected behavior?
> So I'm unsure how to postMessage back to chrome.
Most simply:
win.wrappedJSObject._firebugConsoleWindow = {
postMessage: function firebugPostMessage(msg, origin) {
return window.postMessage(msg, origin);
}
};
should do the trick.
-Boris
Axel Hecht
I've seen DOM code that actually inspects the js call stack to get the
arguments, and has an idl of just (). Usually those have a remark "only
to be called from JavaScript" in the idl. Not sure if that code needs
C++ or can be in js itself.
Axel
John J Barton
I've not done exactly what you suggest yet, but in trying to get my
cruder version working I discovered that window.postMessage() seems to
be asynchronous. That significantly affects it's use in logging: all of
the output is now the last message written. Which is ok if that is the
log message you need to read. Else not. ;-)
jjb
>
> -Boris
Boris Zbarsky
> I've not done exactly what you suggest yet, but in trying to get my
> cruder version working I discovered that window.postMessage() seems to
> be asynchronous.
Yes, absolutely. That's the whole point of it.
> That significantly affects it's use in logging: all of
> the output is now the last message written.
Er... why?
-Boris
johnjbarton
Async causes three kinds of problems.
First, the API is console.log(obj0, obj1, obj2,...);, where obj* are
content objects. We can't postMessage them from content to chrome. In
our current version we push the arguments onto
window._firebug.userObjects, fire an event, handle the event in chrome,
and retrieve the objects from window._firebug. With async messages, the
objects are overwritten before we retrieve them.
This can be fixed by queuing the objects by message id and passing the
id via postMessage. Already we are getting hacky.
Second, the console semantics wants to render the objects at the time
the content calls console.log(), not later when async call runs and the
objects may have changed values.
This can be fixed by duplicating the object formatting code into the
content window. More hackiness. (One subtle issue here: much of the
power of Firebug's console comes from live object references which will
by definition have this problem, but in practice if the title string is
rendered at the log call the live object reference works well for
developers).
Third, many users of the console attempt to rely on it as an alternative
to symbolic debuggers and profilers. So they use the appearance of log
entries over time as a diagnostic, a very common approach among people
who use printf/dump/etc.
While we may scoff at this crude approach to debugging I am continually
amazed at how many otherwise skilled developers are unfamiliar with or
unmotivated to use symbolic debugging. On the other hand, symbolic
debuggers are notoriously unreliable, so maybe they are onto something.
jjb
>
> -Boris
Blake Kaplan
> That said, it's a little odd to me that in this case the subject
> principal when making the call on the chrome object is not forced to
> system by the COW. Blake, is that the expected behavior?
So, this is a bug that crowder ran into recently. The fix isn't difficult, but
I'm not entirely certain that I want to do it. I think it's better to create
wrapper objects with explicit APIs like:
win.wrappedJSObject._firebugConsoleWindow = {
__exposedProps__: {
postMessage: 'r'
},
postMessage: function firebugPostMessage(msg, origin) {
return window.postMessage(msg, origin);
}
};
that way everything's explicit. If people think that this is too onerous, then
I can patch COWs to allow this.
--
Blake Kaplan
Boris Zbarsky
> Second, the console semantics wants to render the objects at the time
> the content calls console.log(), not later when async call runs and the
> objects may have changed values.
OK. Given this constraint, why are you using postMessage again?
-Boris
johnjbarton
Because the current code is a rat's nest unconventional code that no one
else understands. I gave up on postMessage. I did make one small
improvement, to replace added elements with existing document elements
for the events that trigger function calls with arguments pass via
global variables. That will close four bugs.
jjb
>
> -Boris
Boris Zbarsky
> Because the current code is a rat's nest unconventional code that no one
> else understands.
That explains why you want to get rid of the current code, not why
postMessage is the right replacement.
The right replacement would seem to be a synchronous call on a chrome
object, no?
-Boris
johnjbarton
What does that mean, given that Firebug 1.6 has to support FF 3.6?
jjb
>
> -Boris
>
Boris Zbarsky
> What does that mean, given that Firebug 1.6 has to support FF 3.6?
Ah, I didn't realize we were talking about 1.6. Nevermind, then.
-Boris
johnjbarton
I'll probably take one more shot at replacing our JS-script-loading hack
with Javascript Global Property, then let 1.6 be.
For 1.7 (FF 3.7+) the info in this thread is kinda mixed up, with stuff
about postMessage combined with new things from 3.7 that sound unsettled.
If the synchronous call on a chrome object is settled for 3.7, it would
be great to have a non-postMessage example here to work from.
Thanks,
jjb
Jonas Sicking
So don't use postMessage :)
Simply grab whatever console objects you have internally in firebug and
poke the data directly into those.
The whole gecko API is your oyster.
/ Jonas
Jonas Sicking
For what it's worth, I *think* that most of the stuff that will allow
you to easily expose APIs to webpages (i.e. Blakes wrapper awesomeness,
and my notification) will be backported to 3.6.
Though of course we won't know for sure until it's done.
/ Jonas
Mook
When actually using COWs (which would mostly be transparent), and
hitting this, how would one go about figuring out the problem? That is,
if somebody else reproduced John's problems, how would they know to add
__exposedProps__? According to the error message John posted, there's
nothing at all that indicates wrappers of any sort are involved at all.
That is: I think as it stands things are indeed too onerous since,
effectively, they are "you need to happen to be mrbkap to write working
code". That is obviously not scalable :) I understand of course that
there's going to be some change (either things just work or you need to
write the explicit wrapper object), but, at least, I can't see an
obvious way to get things to be able to hint at the solution when one
encounters an error.
--
Mook