Last Comment Bug 413451 - Bug 413250 allows to steal data from sessionstore.js
: Bug 413250 allows to steal data from sessionstore.js
Status: RESOLVED FIXED
[sg:high]
: verified1.8.1.12
Product: Core
Classification: Components
Component: Security (show other bugs)
: unspecified
: All All
: P1 normal (vote)
: ---
Assigned To: Daniel Veditz [:dveditz]
:
: David Keeler [:keeler] (use needinfo?)
Mentors:
Depends on: 413250
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-22 01:51 PST by moz_bug_r_a4
Modified: 2008-01-30 09:04 PST (History)
19 users (show)
mtschrep: blocking1.9+
dveditz: blocking1.8.1.12+
dveditz: wanted1.8.1.x+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase (352 bytes, text/html)
2008-01-22 01:53 PST, moz_bug_r_a4
no flags Details

Description moz_bug_r_a4 2008-01-22 01:51:41 PST
It's possible to steal data from sessionstore.js including cookies.

I'm filing this bug to attach a testcase since bug 413250 is public.
Comment 1 moz_bug_r_a4 2008-01-22 01:53:04 PST
Created attachment 298422 [details]
testcase

This requires Download Statusbar:
https://addons.mozilla.org/en-US/firefox/addon/26
Comment 2 Mike Schroepfer 2008-01-22 16:35:07 PST
Yea - we should fix this asap...
Comment 3 Daniel Veditz [:dveditz] 2008-01-22 19:54:10 PST
I worried about that one :-(
Comment 4 Daniel Veditz [:dveditz] 2008-01-23 10:24:33 PST
trunk no longer uses sessionstore.js, but if it's an upgraded Firefox 2 profile we don't clean up and there may still be juicy stuff available. I'll file a bug on that aspect.

I thought we were going to make the Object and Array prototypes immutable to prevent this kind of attack? Is that something that has to wait for JS2?
Comment 5 Daniel Veditz [:dveditz] 2008-01-23 10:30:54 PST
filed bug 413689 about stale sessionstore.js data in a FF3 profile.
Comment 6 Jesse Ruderman 2008-01-23 10:51:51 PST
> I thought we were going to make the Object and Array prototypes immutable to
> prevent this kind of attack?

I thought so too, but I'm still waiting for an answer from Brendan in bug 376957.
Comment 7 Brendan Eich [:brendan] 2008-01-23 12:02:57 PST
Jesse: it's not a mystery. Waldo patched SpiderMonkey to use the original values of Object and Array (and their prototype objects, which while mutable are bound by immutable 'prototype' properties in the ctor objects) when interpreting object and array initialisers. So no replacing or shadowing attacks are possible, but getters on the prototype can still be abused, maybe.

/be
Comment 8 Jeff Walden [:Waldo] (remove +bmo to email) 2008-01-24 14:42:50 PST
Last I remember, shaver's patch in bug 322889 would make sets and gets not use getters/setters -- might be worth seeing what happens with that patch in place, if it's ready enough.
Comment 9 Jeff Walden [:Waldo] (remove +bmo to email) 2008-01-24 15:03:26 PST
Of course, that's only Array and not Object, so that might not be meaningful here.
Comment 10 Daniel Veditz [:dveditz] 2008-01-24 22:58:48 PST
Fix for bug 413250 checked in.
Comment 11 Giorgio Maone [:mao] 2008-01-28 22:35:36 PST
http://www.hiredhacker.com/2008/01/19/firefox-chrome-url-handling-directory-traversal/

has just been updated with a demo covering this very facet of the bug:

http://www.hiredhacker.com/steal_sessionstore.html

Still keeping this private? When can 2.0.0.12 be released?
Comment 12 Daniel Veditz [:dveditz] 2008-01-29 00:03:47 PST
Release candidate builds are being generated now (see the usual nightly release directories). I'd like to give Window a chance to update http://blog.mozilla.com/security before opening up this bug -- drawing more attention to the problem just puts more people at risk, we're already going as fast as we can on the release.
Comment 13 georgi - hopefully not receiving bugspam 2008-01-29 00:04:42 PST
though chrome: traversal seems fixed on trunk and latest-2.0,
resource: traversal still works.

resource:///%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f
^^^ this is "/"
resource:///%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2fetc
^^^ this is "/etc"
(in case you don't get /, add more %2e%2e%2f

even more:
<script src="resource:///%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2fetc">
works from the web.

this means it is possible to read at least some js files if the full
path is known via 'resource:///'.
Comment 14 georgi - hopefully not receiving bugspam 2008-01-29 00:20:38 PST
resource stuff is public Bug 394075

this is none of my business, but i don't see any point in releasing .12 with resource: wide open - it is too similar to chrome: traversal
Comment 15 Daniel Veditz [:dveditz] 2008-01-29 01:14:26 PST
> resource stuff is public Bug 394075

No, bug 380994
Comment 16 Al Billings [:abillings] 2008-01-29 16:28:45 PST
I've verified this fix with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/2008012820 Firefox/2.0.0.12 and Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.12) Gecko/2008012822 Firefox/2.0.0.12. 

With this testcase (attached to bug), we get "undefined" as a result now.

I've also tested and verified bug 413250.

Note You need to log in before you can comment on or make changes to this bug.