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

dsfsdfdsfdsfdsf

ghjghj

Da, interesanta idee, poate fi foarte utila o astfel de utilitate.

Avem o categorie numita "Cos de gunoi" unde mutam toate porcariile. Tu ai postat niste link-uri de 2 lei, nu vad ce ar cauta asa ceva la Show-Off. Ai extras macar versiunea bazei de date? Intrati pe un link, puneti o ghilimea si sunteti 1337.Sau puneti acel link in Havij si sunteti 31337. O sa dau ban pentru astfel de porcarii.

Alcoolul dauneaza grav sanatatii. Lasati cacaturile si faceti ceva constructiv.

Trebuie sa facem "discriminari" apoi. Si pentru ce, pentru niste conturi? Trebuie sa luam in considerare cine si de ce ar avea acces la continut pus de alte persoane, si care persoane sa aiba permisiunea de a posta. Apoi, sincer, ce cacat faceti cu acele conturi? Cate persoane AR POSTA conturi?

Vad doar un link, deci nimic de Show-Off, deci se muta la gunoi.

Asta e "Show Off" ba? Ratatii din ziua de azi... In trecut prin "Show off" se intelegea un Full Disclosure, acum vad numai un cacat de link pe care il bagati in Havij si gata. Muie generatiei "tinere"!

Nu conteaza, e bine pentru inceput.

Ce dracu sa va cer, daca atat va duce capul sa va luati dupa niste copii copaci...

Foarte interesant. Ban. Mi s-a luat de posturi de cacat,

Poate e pentru ca baui, dar ma pis pe amandoi. Muie.

Sa ma fut pe anonimusii vostri ratatilor.

Copii fara viitor, au invatat sa foloseasca Google si au devenit hackeri, patetici.

Eu ii dadeam ban lui Tinkode aici, Tinkode imi dadea ban pe ISR. Ce vremuri

De la ieu pt baety: Florin Salam - Cap si pajura 2011 (Live Club One Million Timisoara) - YouTube

dsfMrdfUfxIcvE AdfNsdOdsfNtyYfgMzOxcUasSdf.

Sa nu va plangeti la mine ca a venit valu' de copii copaci peste voi...

L-am oprit pe Salam ca sa ascult porcaria aia? Muie!

In C un vector e un pointer, adresa de memorie contigua unde e memorat acel vector. Ex. char plm[13] = "Ana are mere"; plm == 0x12345678, adresa de unde incepe acel sir, adica la adresa 0x12345678 e caracterul "A", adica 65, adresa 0x12345679 corespunde lui "n" si tot asa. Tipul de date al vectorului, char, indica faptul ca fiecare element ocupa un octet pentru ca sizeof(char) este 1.

Integer overflow - Wikipedia, the free encyclopedia

Fals. Nu se aloca nimic pentru acel s[256], e un pointer si se vor pune pe stiva 4 octeti (respectiv 8 pentru sisteme pe 64 de biti) indiferent daca e s[1] sau s[1337]. Ii este trimis un pointer la un sir de caractere deja alocat. Practic va copia sirul "dupa" sirul existent (in memorie). Revin cu detalii mai tarziu.

Ce hackeri avem noi? Acestia sunt hackeri? Persoane care ghicesc parole? Persoane care ruleaza o comanda "./scan cacat" si nu stiu ce e ala kernel? Acestia? Apoi, SUA poate "cumpara" persoane capabile, daca are nevoie.

char sir[17] = "SimpleCChallange"; - Asta e const char * void fct(char s[256], int i) { - Aici e char * Nu se poate apela functia, nu se face conversia implicit.