FYI -------- Forwarded Message -------- Subject: Re: [tor-talk] Javascript exploit Date: Wed, 30 Nov 2016 14:28:52 -0500 From: Roger Dingledine <arma@mit.edu> Reply-To: tor-talk@lists.torproject.org To: tor-talk@lists.torproject.org On Wed, Nov 30, 2016 at 12:08:00PM +0000, Georg Koppen wrote:
FWIW: We plan to release 6.0.7 with the patch Mozilla developed in a couple of hours. Updates to the alpha and hardened series will we provided as well thereafter.
Update: * The blog post about the 6.0.7 Tor Browser update will go up any moment. I see that the Tor Browser team has already put the packages in https://dist.torproject.org/torbrowser/6.0.7/ * It looks like the vulnerability was in Firefox's SVG animation, so the exploit does not work unless you have both svg and javascript enabled. The "high" setting of Tor Browser's security slider disables both of these pieces of the browser. * It looks like the exploit code went up on pastebin on Monday morning, and Mozilla worked on a patch yesterday, and updates to Firefox and Tor Browser and Tails are coming out today. The exploit only worked on Windows, but the vulnerability exists for Windows, OS X, and Linux. In the meantime, if you slide your security slider to high, you won't be vulnerable to this issue. --Roger -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
On Wed, Nov 30, 2016 at 02:23:28PM -0700, Mirimir wrote:
-------- Forwarded Message -------- Subject: Re: [tor-talk] Javascript exploit Date: Wed, 30 Nov 2016 14:28:52 -0500 From: Roger Dingledine <arma@mit.edu> Reply-To: tor-talk@lists.torproject.org To: tor-talk@lists.torproject.org
On Wed, Nov 30, 2016 at 12:08:00PM +0000, Georg Koppen wrote:
FWIW: We plan to release 6.0.7 with the patch Mozilla developed in a couple of hours. Updates to the alpha and hardened series will we provided as well thereafter.
This is just a weaponized named example of "multiple memory safety bugz", check the mozilla sickyouarity advisories. The bugzilla bug tracking this is phunny: https://bugzilla.mozilla.org/show_bug.cgi?id=1321066 ======= First, the extended commit message has "MozReview-Commit-ID: 9#Feedback: feedbacker@example.com" on its last line. That looks like a mistake? MozReview-Commit-ID is supposed to contain a longer UUID (longer than "9" :)) ... Yeah, the weird commit message is because Emacs dies while I was editing it while uploading, so there was some extra meta data in there. Sorry about that. I'll fix up the AutoRestore stuff, I was just being lazy. ... Yeah -- a crash is still expected, even in a "good" build with the fix. The difference is whether the crash is safe or not. (Per beginning of comment 13, we'd like to avoid crashing at all, but it's simpler to just abort safely in the error condition for now.) To validate the fix, you should load the interactive testcase and trigger the crash, and then go ahead and submit the crash and check the crash signature. A "bad" crash looks like this: bp-d49b2ac3-2bec-40b1-b633-b81cf2161130 A "good" crash will look a bit different -- it should at least have a "crash address" of 0x0 or close to that, I think. I'm not sure exactly how it'll look because I don't have a expected-"good" build handy. Do you have a link to the build that you're testing? .... Hi Daniel, I just tested it on Windows 10 pro (x64). The crash address is "0x7ff9fb1c05c0". I am not sure if we expected that. Thanks. .... Thanks, Cynthia. I believe the presence of "MOZ_RELEASE_ASSERT" in that crash report means all is well. (Additionally, the backtrace confirms that we're crashing on that new assertion line in AddMilestone, which is just before we set ourselves up for trouble.) I guess MOZ_RELEASE_ASSERT produces a non-null crash address on Windows for some reason; not sure why. But I think that crash report is still fine -- MOZ_RELEASE_ASSERT should be all that we need to look for here. ....
Settle down georgi - I no this kinda stuff excites you -------- Original Message -------- On Dec 4, 2016, 10:16 AM, Georgi Guninski wrote: On Wed, Nov 30, 2016 at 02:23:28PM -0700, Mirimir wrote:
-------- Forwarded Message -------- Subject: Re: [tor-talk] Javascript exploit Date: Wed, 30 Nov 2016 14:28:52 -0500 From: Roger Dingledine <arma@mit.edu> Reply-To: tor-talk@lists.torproject.org To: tor-talk@lists.torproject.org
On Wed, Nov 30, 2016 at 12:08:00PM +0000, Georg Koppen wrote:
FWIW: We plan to release 6.0.7 with the patch Mozilla developed in a couple of hours. Updates to the alpha and hardened series will we provided as well thereafter.
This is just a weaponized named example of "multiple memory safety bugz", check the mozilla sickyouarity advisories. The bugzilla bug tracking this is phunny: https://bugzilla.mozilla.org/show_bug.cgi?id=1321066 ======= First, the extended commit message has "MozReview-Commit-ID: 9#Feedback: feedbacker@example.com" on its last line. That looks like a mistake? MozReview-Commit-ID is supposed to contain a longer UUID (longer than "9" :)) ... Yeah, the weird commit message is because Emacs dies while I was editing it while uploading, so there was some extra meta data in there. Sorry about that. I'll fix up the AutoRestore stuff, I was just being lazy. ... Yeah -- a crash is still expected, even in a "good" build with the fix. The difference is whether the crash is safe or not. (Per beginning of comment 13, we'd like to avoid crashing at all, but it's simpler to just abort safely in the error condition for now.) To validate the fix, you should load the interactive testcase and trigger the crash, and then go ahead and submit the crash and check the crash signature. A "bad" crash looks like this: bp-d49b2ac3-2bec-40b1-b633-b81cf2161130 A "good" crash will look a bit different -- it should at least have a "crash address" of 0x0 or close to that, I think. I'm not sure exactly how it'll look because I don't have a expected-"good" build handy. Do you have a link to the build that you're testing? .... Hi Daniel, I just tested it on Windows 10 pro (x64). The crash address is "0x7ff9fb1c05c0". I am not sure if we expected that. Thanks. .... Thanks, Cynthia. I believe the presence of "MOZ_RELEASE_ASSERT" in that crash report means all is well. (Additionally, the backtrace confirms that we're crashing on that new assertion line in AddMilestone, which is just before we set ourselves up for trouble.) I guess MOZ_RELEASE_ASSERT produces a non-null crash address on Windows for some reason; not sure why. But I think that crash report is still fine -- MOZ_RELEASE_ASSERT should be all that we need to look for here. ....
participants (3)
-
Georgi Guninski -
Mirimir -
rooty