Exploiting CVE-2011-2140 another flash player vulnerability

[Nytro]

[h=2]Exploiting CVE-2011-2140 another flash player vulnerability[/h]Posted by shahin

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.

[h=1]1) Advisory information[/h]

[TABLE]

[TR]

[TD=width: 638] Title : Adobe flash player memory overwrite exploit Version : <= 10.3.186.3 Discovery : Zero Day Initiative Vendor : http://adobe.com Impact : Critical

Contact : info [at] abysssec.com

Twitter : @abysssec

[/TD]

[/TR]

[/TABLE]

[h=1]2) Vulnerability Information[/h]

[TABLE]

[TR]

[TD=width: 638]Class 1- Stack OverwriteImpactSuccessfully exploiting this issue allows remote attackers to gain code execution on vulnerable system Remotely Exploitable

Yes

Locally Exploitable

Yes

[/TD]

[/TR]

[/TABLE]

[h=1]3) Vulnerabilities detail[/h]

[h=2]1- Stack overwrite vulnerability[/h]

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 :

[TABLE]

[TR]

[TD=width: 638].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

[/TD]

[/TR]

[/TABLE]

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.

[TABLE]

[TR]

[TD=width: 638]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

.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

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

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

[/TD]

[/TR]

[/TABLE]

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 .

[h=2]2- Exploitation[/h] 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 !

Sursa: Exploiting CVE-2011-2140 another flash player vulnerability | Abysssec Security Research