386410 - potential js injection in sessionstore.js

Status: RESOLVED INVALID

(Firefox :: Session Restore, defect)

Description

[georgi - hopefully not receiving bugspam]

potential js injection in sessionstore.js

$PROFILE/sessionstore.js seems javascript that gets executed.
it is possible to include the following:
_hosts:{localhost:true, true:true}
true:true is invalid construct.

to reproduce.
put a name in /etc/hosts for a host "true".
visit "http://true".
open $PROFILE/sessionstore.js and search for "true:true".

this seems to need investigating.

Comment 1

[Simon Bünzli]

(In reply to comment #0)
> it is possible to include the following:
> _hosts:{localhost:true, true:true}

{true:true} has become a valid construct in Gecko 1.9; Firefox 2.0 produces _hosts:{'true':true} instead - so it's not possible to cause dataloss by just visiting http://true.

Furthermore, sessionstore.js is evaluated inside a sandbox and the result is used as an object consisting only of Object, Array, Number, String and null - i.e. nothing is evaluated at all.

At worst it might be possible to override the getter for known properties from inside sessionstore.js, but there's no way of introducing a function into the object in the first place (since as above, all values are guaranteed to be Number, String or null when retrieved over XPCOM and we only add Object and Array ourselves). So this attack vector could at most only be used when an attacker already has write-access to the profile directory - and then there are easier ways to compromise Firefox.

Not seeing any issue here, let alone a danger of js injection -> INVALID

BTW: _hosts is something which doesn't really belong into sessionstore.js at all - it's overwritten before it's used again and was only kept internally in the original implementation, where all properties starting with an underscore were never written to disk (which no longer is the case as _closedTabs IS reused).

Comment 2

[georgi - hopefully not receiving bugspam]

the 2.0 quoting behaviour seems better, though ability to insert single quote may break it (couldn't insert it).

|true: true| seems invalid in trunk-latest and
|if: true| certainly isn't.

anyway resolve as you wish.

Comment 3

[Simon Bünzli]

(In reply to comment #2)
> the 2.0 quoting behaviour seems better,

It's unnecessary, though, since you (resp. the JS enginge) can easily see the difference between an Object's property name, a value or a language construct's keyword.

Try evaluating ({true:true, if:"if"}) in Firefox 3's Error Console and you'll see that it does the right thing. If it didn't, that would be a bug against the JavaScript engine since other components might rely on that behavior of eval/uneval as well. (note the parentheses though, they're required - and of course present in sessionstore.js as well)

> though ability to insert single quote may break it (couldn't insert it).

If you actually could insert an unescaped apostrophe or quotation mark there without directly editing sessionstore.js, that would once more be a fault in JavaScript's uneval/toSource. The extensive JavaScript test suite should find such a regression pretty much immediately, though.

BTW: Even directly editing sessionstore.js only wins you something when Firefox is NOT running (resp. when no browser window is opened with bug 354894 being fixed), since otherwise that file gets overwritten regularly without being read/evaluated at all.

So, either you find a JS bug to exploit which either leads to dataloss here or compromises all users of the Sandbox, or you find a way to modify a file while no browser window is opened. Both cases would be far more general than what SessionStore does and should be filed against the corresponding component. Closing this bug as INVALID (please remove the security-sensitive flag).

Comment 4

[georgi - hopefully not receiving bugspam]

(In reply to comment #3)
> 
> Try evaluating ({true:true, if:"if"}) in Firefox 3's Error Console and you'll

yes it works, i have missed something.


> BTW: Even directly editing sessionstore.js only wins you something when Firefox
> is NOT running (resp. when no browser window is opened with bug 354894 being

probably unless you manage to force exit via some of the numerous null dereferences or other stuff?