31 Jan

Exploiting CVE-2011-2140 another flash player vulnerability

Posted by shahin in Uncategorized |

hello all .

before going future we are sorry to not update blog regularly, but it’s due to we are busy with stack of projects and also working on our expert training courses.

so as we didn’t post any blog post here we go with another flash player exploit we wrote long time ago.

 

1) Advisory information

 

  Title                   :  Adobe flash player memory overwrite exploit   Version             :  <= 10.3.186.3  Discovery         :  http://www.zerodayinitiative.com/advisories/ZDI-11-276/  Vendor             :  http://adobe.com

  Impact              :  Critical

  Contact            :   info  [at] abysssec.com

  Twitter             :   @abysssec

 

2) Vulnerability Information

 

Class        1- Stack OverwriteImpactSuccessfully exploiting this issue allows remote attackers to gain code execution on vulnerable system

Remotely Exploitable

Yes

Locally Exploitable

Yes

 

 

3) Vulnerabilities detail

 

1- Stack overwrite vulnerability

 

Before we go deep into the vulnerability for understanding this vulnerability you should take a look at MP4 format and H.264/AVC data structures.The actual vulnerability occurs during processing data units in Sequence Parameter Set in MP4. Sub_1005B396 function, is responsible for processing   Sequence Parameter Set. In this function pic_order_cnt_type from SPS will be check, if it’s equal with 1, other fields like data_pic_order_always_zero_flag , offset_for_non_ref_pic , offset_for_top_to_bottom_field  will be initialize :

.text:1005B396 sub_1005B396    proc near               ; CODE XREF: sub_1005B8DB+4Bp.text:1005B397                 push    ebp.text:1005B398                 push    esi.text:1005B399                 push    edi

.text:1005B39A                 mov     edi, ecx

.text:1005B39C                 call    sub_1005A95B

.text:1005B3A1                 mov     esi, [esp+10h+arg_0]

.text:1005B3A5                 mov     ecx, edi

.text:1005B3A7                 mov     [esi], al

 

…

 

.text:1005B47D                 mov     ecx, edi

.text:1005B47F                 mov     [esi+20h], eax

.text:1005B482                 call    sub_1005AA64

.text:1005B487                 mov     [esi+40h], eax

.text:1005B48A                 cmp     eax, ebp             à     if( pic_order_cnt_type )

.text:1005B48C                 jnz     short loc_1005B49D

 

…

 

.text:1005B49D loc_1005B49D:                           ; CODE XREF: sub_1005B396+F6j

.text:1005B49D                 xor     ebx, ebx

.text:1005B49F                 inc     ebx

.text:1005B4A0                 cmp     eax, ebx            à       if( pic_order_cnt_type == 1 )

.text:1005B4A2                 jnz     short loc_1005B4EF

.text:1005B4A4                 mov     ecx, edi

.text:1005B4A6                 call    sub_1005A99A    à       offset_for_top_to_bottom_field

.text:1005B4AB                 mov     ecx, edi

.text:1005B4AD                 mov     [esi+48h], al

.text:1005B4B0                 call    sub_1005AA93    à        offset_for_non_ref_pic

.text:1005B4B5                 mov     ecx, edi

.text:1005B4B7                 mov     [esi+54h], eax

.text:1005B4BA                 call    sub_1005AA93    à         offset_for_top_to_bottom_field

 

Then the num_ref_frames_in_pic_order_cnt_cycle will be set and if it’s bigger than 0 the values in offset_for_ref_frame will be copied into buffer.

text:1005B4BF                 mov     ecx, edi.text:1005B4C1                 mov     [esi+50h], eax.text:1005B4C4                call    sub_1005AA64      à    num_ref_frames_in_pic_order_cnt_cycle.text:1005B4C9                 mov     [esi+4Ch], eax

.text:1005B4CC                 test    eax, eax

.text:1005B4CE                 jbe     short loc_1005B4EF

.text:1005B4D0                 lea     eax, [esi+58h]

.text:1005B4D3                 mov     [esp+10h+arg_0], eax

.text:1005B4D7

.text:1005B4D7 loc_1005B4D7:                                             à         do{

.text:1005B4D7                 mov     ecx, edi

.text:1005B4D9                 call    sub_1005AA93                    à         offset_for_ref_frame[i]

.text:1005B4DE                 mov     ecx, [esp+10h+arg_0]

.text:1005B4E2                 add     [esp+10h+arg_0], 4            à          buf = &buf + 4

.text:1005B4E7                 inc     ebp                                      à          i++

.text:1005B4E8                 mov     [ecx], eax                           à          buf = offset_for_ref_frame[i]

.text:1005B4EA                 cmp     ebp, [esi+4Ch]

.text:1005B4ED                 jb      short loc_1005B4D7             à          } while(i < num_ref_frames_…)   

You should got the vulnerability at this point. There is no boundary check for num_ref_frames_in_pic_order_cnt_cycle, so our data related to  offset_for_ref_frame will be copy into the stack , that’s all .

 

 

2- Exploitation

Thanks to windows memory manager, browser and class of bug it’s not that hard to archive RCE. The only thing that should care about is return address. Because values which copied from MP4 file into stack, come with the changes. In other words, these values ​​after reading from file will be decode and then are copied into stack. Values ​​are copied into the buffer are generated from values in file into Signed Exp-Golomb code.After taking controll of EIP it’s easy to finish the job we used basic heap spray.

here is reliable exploit : CVE-2011-2140

happy hunting !

 

 

Get Adobe Flash playerPlugin by wpburn.com wordpress themes