Closed Bug 905993 Opened 6 years ago Closed 6 years ago

Dangerous Crash on Heap (reproduces only cleanly on ASan)

Categories

(Core :: JavaScript Engine, defect, critical)

x86_64
All
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla26
Tracking Status
firefox22 --- unaffected
firefox23 --- unaffected
firefox24 + fixed
firefox25 + fixed
firefox26 + fixed
firefox-esr17 --- unaffected
b2g18 --- unaffected

People

(Reporter: decoder, Assigned: jandem)

References

(Blocks 1 open bug)

Details

(4 keywords)

Attachments

(1 file)

The following testcase crashes on mozilla-central revision 1ed5a88cd4d0 (run with --fuzzing-safe --ion-eager):


Object.prototype[(0)] = 3;
var N = 1 << 16;
var array = Array(50);
for (var i = 0; i != N/2; ++i)
  array[i] = i;
Since approximately August 05, I am seeing random crashes on the heap on all fuzzers. Unfortunately, none of these reproduce cleanly, they reproduce in 1% of all runs and are very hard to reduce and long running.

Fortunately, it seems that on the ASan builds, I've found the same bug, just that it reproduces quicker and more cleanly. This *could* be due to different memory layout/initialization that ASan chooses. The crash looks like this:


Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7e8e15a in ?? ()
(gdb) bt
#0  0x00007ffff7e8e15a in ?? ()
#1  0x00007ffff7e81564 in ?? ()
#2  0x0000000000000183 in ?? ()
#3  0x00007ffff6855101 in ?? ()
#4  0x0000000000000000 in ?? ()
(gdb) x /i $pc
=> 0x7ffff7e8e15a:      mov    %edx,(%rbx,%rbx,8)
(gdb) info reg rbx
rbx            0x609a00000210   106214541230608
(gdb) info reg edx
edx            0x641    1601


On the non-ASan slaves, the crashes looked the same, in particular the register pattern. Jandem mentioned that the register pattern here might be characteristic for the bug.

Marking this at least sec-high for now.
Keywords: sec-high
Regression from bug 900890, which was backported to aurora and beta a few days ago.
Assignee: general → jdemooij
Status: NEW → ASSIGNED
OS: Linux → All
Attached patch PatchSplinter Review
One-liner.
Attachment #791255 - Flags: review?(nicolas.b.pierron)
Comment on attachment 791255 [details] [diff] [review]
Patch

> [Security approval request comment]
> How easily could an exploit be constructed based on the patch?

Not trivial, but it's doable for somebody who knows what he's doing.

> Do comments in the patch, the check-in comment, or tests included
> in the patch paint a bulls-eye on the security problem?

No.

> Which older supported branches are affected by this flaw?

Bug 900890 was backported to aurora and beta a few days ago, so aurora and beta are affected too.

> If not all supported branches, which bug introduced the flaw?

Bug 900890.

> Do you have backports for the affected branches? If not, how different,
> hard to create, and risky will they be?

Should apply to older branches, just a one-liner.

> How likely is this patch to cause regressions; how much testing does it need?

Unlikely, and it should only affect 64-bit.
Attachment #791255 - Flags: sec-approval?
Comment on attachment 791255 [details] [diff] [review]
Patch

sec-approval+ for trunk.

Once it is there, it is approved for beta and aurora. Let's try to avoid shipping the problem behavior. Please get this in soon so it gets released in a few betas.
Attachment #791255 - Flags: sec-approval?
Attachment #791255 - Flags: sec-approval+
Attachment #791255 - Flags: approval-mozilla-beta+
Attachment #791255 - Flags: approval-mozilla-aurora+
Attachment #791255 - Flags: review?(nicolas.b.pierron) → review+
https://hg.mozilla.org/mozilla-central/rev/a3788b319566
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → mozilla26
Group: core-security
You need to log in before you can comment on or make changes to this bug.