mboost-dp1
Microsoft Corporation
Hvis at mit gæt angående naturen af denne bug er korrekt(addresserne ligner stack addresser ikke heap addresser), er der mange andre ting der kan spille ind.
Bla.:
Det er ikke sikkert at vi kan få fat i hvorhenne vi er i hukommelsels layoutet, så kan vi bruge http://en.wikipedia.org/wiki/Heap_spraying
Det er ikke sikkert at vi har direkte indflydelse på hvordan vi kan påvirke hvad der ligger i den buffer direkte.Så bliver vi nødt til at reverse engineere hvordan data ender der, og gøre det baglæns- et eksempel kan være:"Tegn et .bmp billede der ender med at være x86 opcodes"
Måske kan vi kun påtvinge en regnefejl der gør at vi lander i specifikke hukommelses områder, der er på heapen istedet for stacken. Så kan vi prøve at overwrite andre returnerings addresser i structs.
og nogle gange(ved strcpy) kan vi ikke injecte data der ender med at indeholde et 00 memory segment.
Der er rigtigt mange ting der kan spille ind inden man kan lave en working exploit, og det hele afhænger af hvordan koden der har en bug er lavet.
Det første skridt er altid at få et program til at chrashe, når det chrasher betyder man at man har manipuleret med hukommelses områder på en måde programmøren ikke har forventet.
Det næste skridt er så at reverse engineere hvad der har ledt til chrashet, og på en måde opnå at det ikke chrasher, men kommer til at køre user inputtet data som om det var executable code.
Denne fejl er særligt slem da den resulterer i en BSOD, det betyder at chrashet er sket i kernel kode der har adgang til alt. Når kernel kode crasher kan det ikke bare vælge at lukke en process, da processen er kernellen.
Sidst en lignende exploit blev opdaget var http://www.sans.org/reading_room/whitepapers/threa... - og der gik ikke lang tid inden der var POCS ude der gav adgang til at køre vilkårlig kode.
Bla.:
Det er ikke sikkert at vi kan få fat i hvorhenne vi er i hukommelsels layoutet, så kan vi bruge http://en.wikipedia.org/wiki/Heap_spraying
Det er ikke sikkert at vi har direkte indflydelse på hvordan vi kan påvirke hvad der ligger i den buffer direkte.Så bliver vi nødt til at reverse engineere hvordan data ender der, og gøre det baglæns- et eksempel kan være:"Tegn et .bmp billede der ender med at være x86 opcodes"
Måske kan vi kun påtvinge en regnefejl der gør at vi lander i specifikke hukommelses områder, der er på heapen istedet for stacken. Så kan vi prøve at overwrite andre returnerings addresser i structs.
og nogle gange(ved strcpy) kan vi ikke injecte data der ender med at indeholde et 00 memory segment.
Der er rigtigt mange ting der kan spille ind inden man kan lave en working exploit, og det hele afhænger af hvordan koden der har en bug er lavet.
Det første skridt er altid at få et program til at chrashe, når det chrasher betyder man at man har manipuleret med hukommelses områder på en måde programmøren ikke har forventet.
Det næste skridt er så at reverse engineere hvad der har ledt til chrashet, og på en måde opnå at det ikke chrasher, men kommer til at køre user inputtet data som om det var executable code.
Denne fejl er særligt slem da den resulterer i en BSOD, det betyder at chrashet er sket i kernel kode der har adgang til alt. Når kernel kode crasher kan det ikke bare vælge at lukke en process, da processen er kernellen.
Sidst en lignende exploit blev opdaget var http://www.sans.org/reading_room/whitepapers/threa... - og der gik ikke lang tid inden der var POCS ude der gav adgang til at køre vilkårlig kode.
Det var en skam den artikel ikke fandtes dengang jeg prøvede at overbevise V8 udviklerne om at output fra JIT compileren skulle holdes adskilt fra data således at man ikke var nødt til at gøre alle data eksekverbar.Mamad (moveax1ret) (51) skrev:Det er ikke sikkert at vi kan få fat i hvorhenne vi er i hukommelsels layoutet, så kan vi bruge http://en.wikipedia.org/wiki/Heap_spraying
Jeg havde aldrig hørt om begrebet heap spraying, men da jeg hørte om designet af V8 fandt jeg hurtigt på metoden. Jeg syntes metoden var oplagt, men det var først i dag jeg fandt ud af at den havde et navn.
Hvis man kan undgå at data er eksekverbar udgør det en forholdsvis effektiv beskyttelse imod heap spraying.
Der er andre måder at beskytte sig imod heap spraying. Muligvis udgør Chromes sandkasse tilstrækkelig beskyttelse.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund