Bugzilla@Mozilla – Bug 568564
Suppress the script filename for cross-origin error events (SA39925)
Last modified: 2010-08-20 18:49:24 PDT
Summon comment box
See http://secunia.com/advisories/39925
In particular, we need to do that because on redirects we put the post-redirect URI into the JSScript filename field. If js error reports had an origin not tied to filename, we could take various other approaches here.
Created attachment 447792 [details] [review] Like so
*** Bug 568688 has been marked as a duplicate of this bug. ***
Proof of concept: http://0me.me/demo/XSUH/XSUH_demo_firefox_all_in_1.html
Shouldn't it block 3.6.4?
*** Bug 569550 has been marked as a duplicate of this bug. ***
Until it gets a sg evaluation it'll be needed but not hard blocking any of the upcoming branch releases; obviously would like a reviewed patch ASAP, but I know people's review queues are busy.
The severity really depends on what information sites reveal through URLs. * http://0me.me/demo/XSUH/XSUH_demo_firefox_all_in_1.html got my Google profile ID, and thus a good guess at my email address. That's a pretty bad privacy violation. * In theory, a site might reveal a session token. If high-profile sites turned out to do that, we'd call this bug [sg:high].
Self-defense until fixed: block 3rd party cookies and the victim sites can't reveal any personal information.
Pushed http://hg.mozilla.org/mozilla-central/rev/155d4a2be1bc and then http://hg.mozilla.org/mozilla-central/rev/6043ca0d3fba to fix test issues. Will create a roll-up patch for branches.
Created attachment 450044 [details] [review] 1.9.2 fix
Created attachment 450045 [details] [review] 1.9.1 merge
Comment on attachment 450045 [details] [review] 1.9.1 merge a=LegNeato for 1.9.2.6 and 1.9.1.11. Please land this on mozilla-1.9.2 default and mozilla-1.9.1 default.
Pushed: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/5fbb842f2ca3 http://hg.mozilla.org/releases/mozilla-1.9.2/rev/29d60ff7f571
is this really fixed? why http://secunia.com/community/forum/thread/show/4596/firefox_3_6_4_released why is this happening (to me!)? i mean, why secunia folks don't think this is fixed? it's their problem? it's mozilla's? is this a situation of ineffective communication?
It's fixed on the default 1.9.2 branch as stated, so will be in the next release, Firefox 3.6.7 If you're desperate for a preview build of it, get http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/3.6.7-candidates/build1/win32/en-US/Firefox%20Setup%203.6.7.exe
> is this really fixed? Yes, but the fix hasn't been shipped yet. It's fixed in the upcoming 1.9.2.x security release, as comment 16 says.
@Mardeg OK now I see the "clegnitto: approval1.9.2.7+". Sorry for my blindness. Thx for the info and the tip. @bz thx!
Comment on attachment 450045 [details] [review] 1.9.1 merge Requesting approval1.9.0.next on this patch so that we can take it in upcoming Camino 2.0.x security and stability updates. If approved, I'll handle the checkins, unless the patch author requests otherwise.
Comment on attachment 450045 [details] [review] 1.9.1 merge Approved for 1.9.0.20, a=dveditz
Checking in content/base/test/test_bug461735.html; /cvsroot/mozilla/content/base/test/test_bug461735.html,v <-- test_bug461735.html new revision: 1.2; previous revision: 1.1 done Checking in dom/src/base/nsJSEnvironment.cpp; /cvsroot/mozilla/dom/src/base/nsJSEnvironment.cpp,v <-- nsJSEnvironment.cpp new revision: 1.402; previous revision: 1.401 done