Bugzilla@Mozilla – Bug 461735
[FIX]Security: theft of strings cross-domain with redirect, <script src> and window.onerror
Last modified: 2011-03-01 05:31:15 PST
Summon comment box
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.16) Gecko/20080716 Firefox/2.0.0.16 Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.16) Gecko/20080716 Firefox/2.0.0.16 The URL above demos the problem nicely. Note that this is with FF3.0.3. This is essentially a new twist to the existing bug: https://bugzilla.mozilla.org/show_bug.cgi?id=363897 This bug was fixed in FF3, but the fix can be bypassed with the redirector trick. Also note that the bug referenced above underestimates the severity of leaking JS error messages cross-domain. Hopefully my demo illustrates that. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 345199 [details] [review] Let's use the final channel URI for the script filename
bz, is this the same issue you mentioned in 363897 comment 10?
Somewhat. Fixing that issue would certainly fix this bug, but we can fix this bug without going to a principal-based check here.
By the way, theft is not limited to just a single word. If you have a CSV file such as: a, b, 12345, c Then is it possible to steal the textual content "a", "b" and "c" by: - Steal "a" using above trick. - Define "a" and rerun exploit. - Steal "b" using above trick. - etc., repeat Strongly recommend backport to FF2
Comment on attachment 345199 [details] [review] Let's use the final channel URI for the script filename Would be good to get trunk/beta baking so that this can land on branches ASAP.
Comment on attachment 345199 [details] [review] Let's use the final channel URI for the script filename a=beltzner
Pushed changeset ffeecd437beb.
Created attachment 347349 [details] [review] 1.9.0 port
Created attachment 347353 [details] [review] 1.8 port
Comment on attachment 347353 [details] [review] 1.8 port Approved for 1.8.1.19, a=dveditz for release-drivers
Comment on attachment 347349 [details] [review] 1.9.0 port Approved for 1.9.0.5, a=dveditz for release-drivers
Fixed on both branches.
With both 1.8.1.18 and the nightly 1.8.1.19 build, http://cevans-app.appspot.com/static/ff3scriptredirbug.html gives an alert that looks like: "The page at http://cevans-app.appspot.com says: dd2afe8343e40cf09400b581912d0e6f is not defined at http://csftpd.beasts.org/steal_me/hex.txt: 1" 1.9.0.4 shows this as well but 1.9.0.5 seems fixed and gives a script error instead. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5pre) Gecko/2008112505 GranParadiso/3.0.5pre So, this does not seem to be fixed on 1.8.1.19.
I'm still seeing this in the latest 1.8.1.19 build: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.19pre) Gecko/2008120103 BonEcho/2.0.0.19pre.
Looks like bug 363897 never got fixed on the 1.8 branch, does this fix rely on that one?
Yes, this one is just a refinement to that one.
Fix for bug 363897 checked into the 1.8 branch, fixing this one. Waiting for tinderbox to clear before checking into the _RELBRANCH
On the _RELBRANCH now.
This doesn't seem fixed (again)! Using the official 1.8.1.19 release build on OS X, when I go to http://cevans-app.appspot.com/static/ff3scriptredirbug.html, I still get an alert that looks like: "The page at http://cevans-app.appspot.com says: dd2afe8343e40cf09400b581912d0e6f is not defined at http://csftpd.beasts.org/steal_me/hex.txt: 1" This is the unfixed behavior. On 3.0.5 and Trunk, I get an alert stating: "The page at http://cevans-app.appspot.com says: Script error. at http://csftpd.beasts.org/steal_me/hex.txt: 0"
My bad, I grabbed build 1 accidentally. This is fixed correctly in build 2. Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.19) Gecko/2008120316 Firefox/2.0.0.19
Created attachment 351895 [details] [review] 1.8.0 branch patch Just for the record, it contains original 1.8 patch + build fixes checked in lately.
Comment on attachment 351895 [details] [review] 1.8.0 branch patch a=asac for 1.8.0
Due to an error, the win32 builds that shipped today for Firefox 2.0.0.19 do not contain the fix from bug 363897, so the fix from this bug doesn't work there. Not sure what to do with the keywords to capture this.
Removing verified1.8.1.19 as per comment 23
But it was verified in the builds we built, and shipped on two out of three platforms. It's better to clone the bug for win32 I think.
Filed bug 470027 to cover reshipping win32
After installation of 3.0.5, I am facing problem with Greasemonkey scripts. by any chance has this fix resulted into a issue similar to https://bugzilla.mozilla.org/show_bug.cgi?id=405394 ?
The issue reported at http://secunia.com/advisories/39925 seems similar; did this, perhaps, regress?
This PoC works in Firefox 3.6: http://0me.me/demo/XSUH/XSUH_demo_firefox_all_in_1.html Not sure if it's the same bug or not.
It's not quite, though it's pretty similar. Actually, it's even more similar to bug 363897, where we suppressed the line number and error text but not the filename.
Filed bug 568564 on that issue.