Fwd: Re: [tor-talk] Javascript exploit

[rooty]

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 at mit.edu>
> Reply-To: tor-talk at lists.torproject.org
> To: tor-talk at 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 at 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.
....
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 3179 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/cypherpunks/attachments/20161204/4183c93a/attachment.txt>