Closed
Bug 568564
(CVE-2010-2754)
Opened 15 years ago
Closed 15 years ago
Suppress the script filename for cross-origin error events (SA39925)
Categories
(Core :: DOM: Core & HTML, defect)
Core
DOM: Core & HTML
Tracking
()
People
(Reporter: bzbarsky, Assigned: bzbarsky)
References
()
Details
(Keywords: fixed1.9.0.20, privacy, Whiteboard: [sg:moderate])
Attachments
(3 files)
2.16 KB,
patch
|
jst
:
review+
|
Details | Diff | Splinter Review |
2.94 KB,
patch
|
christian
:
approval1.9.2.7+
|
Details | Diff | Splinter Review |
2.96 KB,
patch
|
christian
:
approval1.9.1.11+
dveditz
:
approval1.9.0.next+
|
Details | Diff | Splinter Review |
Updated•15 years ago
|
status1.9.1:
--- → wanted
status1.9.2:
--- → wanted
Summary: Suppress the script filename for cross-origin error events → Suppress the script filename for cross-origin error events [Secunia Advisory SA39925]
![]() |
Assignee | |
Comment 1•15 years ago
|
||
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.
![]() |
Assignee | |
Comment 2•15 years ago
|
||
Attachment #447792 -
Flags: review?(jst)
Updated•15 years ago
|
OS: Mac OS X → All
Hardware: x86 → All
Summary: Suppress the script filename for cross-origin error events [Secunia Advisory SA39925] → Suppress the script filename for cross-origin error events (SA39925)
Version: Trunk → unspecified
Comment 4•15 years ago
|
||
Proof of concept:
http://0me.me/demo/XSUH/XSUH_demo_firefox_all_in_1.html
Comment 5•15 years ago
|
||
Shouldn't it block 3.6.4?
![]() |
Assignee | |
Updated•15 years ago
|
blocking1.9.1: --- → ?
blocking1.9.2: --- → ?
blocking2.0: --- → ?
Comment 7•15 years ago
|
||
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.
blocking1.9.1: ? → needed
blocking1.9.2: ? → needed
blocking2.0: ? → beta1+
Whiteboard: [sg:?]
Updated•15 years ago
|
Attachment #447792 -
Flags: review?(jst) → review+
Updated•15 years ago
|
Whiteboard: [sg:low] → [sg:moderate]
Comment 8•15 years ago
|
||
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].
Comment 9•15 years ago
|
||
Self-defense until fixed: block 3rd party cookies and the victim sites can't reveal any personal information.
![]() |
Assignee | |
Comment 10•15 years ago
|
||
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.
Status: NEW → RESOLVED
Closed: 15 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
![]() |
Assignee | |
Comment 11•15 years ago
|
||
Attachment #450044 -
Flags: approval1.9.2.5?
![]() |
Assignee | |
Comment 12•15 years ago
|
||
Attachment #450045 -
Flags: approval1.9.1.11?
Attachment #450044 -
Flags: approval1.9.2.5? → approval1.9.2.6+
Comment 13•15 years ago
|
||
Comment on attachment 450045 [details] [diff] [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.
Attachment #450045 -
Flags: approval1.9.1.11? → approval1.9.1.11+
![]() |
Assignee | |
Comment 14•15 years ago
|
||
Comment 15•15 years ago
|
||
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?
Comment 16•15 years ago
|
||
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
![]() |
Assignee | |
Comment 17•15 years ago
|
||
> 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.
Comment 18•15 years ago
|
||
@Mardeg OK now I see the "clegnitto: approval1.9.2.7+". Sorry for my blindness. Thx for the info and the tip.
@bz thx!
Updated•15 years ago
|
Alias: CVE-2010-2754
Comment on attachment 450045 [details] [diff] [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.
Attachment #450045 -
Flags: approval1.9.0.next?
Comment 20•15 years ago
|
||
Comment on attachment 450045 [details] [diff] [review]
1.9.1 merge
Approved for 1.9.0.20, a=dveditz
Attachment #450045 -
Flags: approval1.9.0.next? → approval1.9.0.next+
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
Keywords: fixed1.9.0.20
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•