Fighting against Flash 0-day

(1)

(2)

Fighting against Flash 0-day

Andrey Kovalev, Konstantin Otrashkevich, Evgeny Sidorov

(3)

Agenda

3

Short Intro

Flash internals & use-after-free in general Popular Flash exploits

Detection

Google Mitigations

Life after G’s mitigations etc.

(4)

Short Intro

(5)

Why Flash exploitation is so popular?

5

2013: Java exploits were the main ‘workhorse’

January 2014: Oracle blocked the execution of unsigned applets June 2014: isolated heap and delayed frees in MS IE

Exploit developers focused on Adobe Flash

(6)

Why Flash exploitation is so popular?

Cross platform Cross browser

Can be embedded in other documents and formats Powerful programming opportunities

Very popular in WEB

Flash has less security mitigations than IE

6

(7)

Adobe Flash Code Excitation Vulnerabilities

Source: https://cvedetails.com 7

(8)

Flash internals

(9)

Flash memory allocation

Blocks > 0x7F0 are allocated by system

Need small block, there is an appropriate «freed» block - return the «freed» block

There is no appropriate «freed» block - allocate large memory page, divide it to small equal blocks, return one block

9

(10)

Small blocks allocation

Memory page contains a number of blocks All blocks have the same length

Page Header contains Block Length field at offset 0x12 Block size is aligned with 8 in blocks less than 0x80

In other clocks size is aligned with 16

10 Page Header

+0x12 Block Length

Block 1

Block 2

Block N ...

(11)

Flash memory allocation

11

Page Header

+0x12 Block Length

Block 1

Block 2

Block N ...

Page Header

+0x12 Block Length

Block 1

Block 2 Freed

Block N ...

Page Header

+0x12 Block Length

Block 1

Block N+1 allocated

Block N ...

(12)

Flash Vector.<int> structure

12

Vector.<int> object

ptr to data collection +0x18

length gc ptr

element[0]

element[1]

element[2]

‘the_vector’

...

(13)

Use-after-free in general

13

Fake vMethod vMethod1 Code

vMethod2 Code

vMethodN Code

Process Heap

Fake VPTR

…

Freed Memory

Process Heap, Fake VTBL .text of image

Dangled Pointer

Malicious vMethod Ptr 1

vMethod1 Code vMethod2 Code

vMethodN Code vMethod Ptr N

vMethod Ptr 2 Process Heap

VPTR

…

Dynamic Instance

.text of image

(14)

Vector<uint>.length corruption

14

Developed in 2013 (CVE-2013-0634 Lady Boyle) Became a basis for exploits in 2014 and 2015

(15)

Length corruption exploitation

1. Corrupt Vector<uint>.length field (override it to be 0xffffffff) 2. Read / write arbitrary values in memory to create ROP chain 3. Create fake vtable with an entry that points to ‘pivot’ gadget 4. Overwrite vtable of any object with the fake vtable

5. Call virtual method (execute ROP chain)

15

(16)

Exploitation

16

vulnerability length

corruption memory R/W

fake vtable ROP ROP trigger

(17)

Examples

(18)

18

length Other data length Other data

length Other data

Freed block

length Other data

Other object

CVE-2013-0634 (Lady Boyle)

_loc_2 = "(?i)()()(?-i)||||||||||||||||||||||";

var _loc_20:* = new RegExp(_loc_2, "");

(19)

CVE-2015-0311 (domainMemory UAF)

19

ApplicationDomain.currentDomain.domainMemory m_globalMemoryBase

m_globalMemorySize

ByteArray::Buffer->array

Vector.<uint>

length element[0] ...

expected

UAF

(20)

Length corruption mitigations

(21)

Google Mitigation: buffer heap partitioning

Vector.<int> buffers are allocated in the separate heap

Not powerful on 32-bit systems and 32-bit software due to address space limitations

21

(22)

Google Mitigation: Vector.<*> length validation

An additional cookie and additional check assert(len ^ lenXor == ptr->cookie);

22

(23)

23

ByteArray data 0x00, 0x00, … Vector.<uint>

length lengthXor

ptr

cookie expected

0x00000000

(24)

Vector.<*> length validation bypass

ptr->cookie was near length field

Allocate big ByteArray (1Gb) with null values

Corrupt cookie ptr to point inside the ByteArray (cookie value becomes 0) Corrupt len and lenXor with same values

Fixed by moving cookie from the ptr (to one of the image sections)

24

(25)

Length corruption detection

(26)

Length corruption detection

Behavioral Stateless Reliable

With small overhead

26

(27)

Vector.<int> set_length

27

(28)

28 Page Header

+0x12 Block Length

Block 2

Block N ...

Vector.<int> object

ptr to data collection +0x18

length gc ptr element[0]

element[1]

...

Calculate Page Header ptr

(29)

‘Big’ vectors

‘Big’ vectors can use more than one page Use ‘get_length_of_block’ function

29

(30)

Vector<*>.length corruption detection

Set hook to set_length, [..] operator etc.

In the hook functions:

1. calculate ptr to Page Header 2. get Page Header block size

3. compare it with the value from Vector<..>.length 

detect if vector<..>.length != (Block Size - 8) / sizeof(element)

30

(31)

Results

The mitigation works only for Vector<uint>.length etc.

Made vector<..>.length corruption technique almost useless

31

(32)

Length corruption technique

Image from http://raunds.townvoice.co.uk/wp-content/uploads/sites/20/2014/02/Rip_cat-269x300.jpg 32

(33)

Length corruption strikes

back

(34)

Length corruption strikes back

The mitigation works only for Vector<..>.length Are there other similar objects?

ByteArray is similar to Vector

ByteArray length corruption is used in CVE-2015-7645

34

(35)

ByteArray structure

35

ByteArray object

Buffer +0x40

capacity array ptr

length

ByteArray data

ByteArray::Buffer object

(36)

Conclusions

We developed a reliable detection approach for Length corruption technique

A reliable mitigation for other Vector-like objects is needed

36

(37)

To read

37

Haifei Li ‘Smashing the Heap with Vector’ http://bit.ly/1X61uZD F. Falcon ‘Exploiting Adobe Flash Player in the era of CGF’  

http://ubm.io/1Ynqk4g

Ga1lois & Bo Qu ‘Inside Flash: Flash Exploit Detection Uncovered’  

http://bit.ly/1QBGxlc

Project Zero Blog http://googleprojectzero.blogspot.ru

(38)

Konstantin Otrashkevich <freeoks@yandex-team.ru>

Andrew Kovalev <avkov@yandex-team.ru>

38

Contacts

Evgeny Sidorov <e-sidorov@yandex-team.ru>