ROP sikkerhedsløsning fra Bluehat konference omgået

Synes det er en smagløs overskrift. Har indsendt et dårligt forslag til hvad det ellers kan være. Men helt ærligt synes jeg thimon burde skamme sig lidt over at lave sådan en overskrift.
Resten af indholdet fejler ikke rigtigt noget og generelt en flot indsats fra thimon med at poste her på newz.

#1: Mens nyheden lå i kø, havde den en helt anden overskrift end den nuværende, så du må spanke den fra staff, som har godkendt nyheden og ændret overskriften.

I diskuterer to overskrifter uden at nævne hvad de var, så jeg har ingen anelse om hvorvidt den allerede er blevet ændret igen. Den nuværende overskrift "ROP sikkerhedsløsning fra Bluehat konference omgået" synes jeg er meget passende til artiklen.

Det ville være smart hvis man kunne se ændringshistorik for artikler ligesom man kan for kommentarer.

kasperd (3) skrev:

I diskuterer to overskrifter uden at nævne hvad de var, så jeg har ingen anelse om hvorvidt den allerede er blevet ændret igen. Den nuværende overskrift "ROP sikkerhedsløsning fra Bluehat konference omgået" synes jeg er meget passende til artiklen.

Det ville være smart hvis man kunne se ændringshistorik for artikler ligesom man kan for kommentarer.

Jeg er ret sikker på at det er overskriften ikke er ændret efter "artiklen" har ramt forsiden af newz.dk

kasperd (3) skrev:

I diskuterer to overskrifter uden at nævne hvad de var, så jeg har ingen anelse om hvorvidt den allerede er blevet ændret igen

Noget i stil med "Microsoft bruger 50.000$ på ubrugelig kode" eller sådan.

I så fald var overskriften helt forkert. Hele fejlen ligger i at man kalder det et "antihackingssystem".

Som der står med store bogstaver, og som navnet antyder, så er EMET: "A toolkit for deploying and configuring security mitigation technologies".

Og for folk som er i tvivl (thimon / Newz staff):
mitigation, substantiv
* formildelse
* reduktion
* nedsættelse
* lindring

Hele idéen med toolkit'et er at nemt, hurtigt og effektivt sikre sine programmer via diverse 'lindrende' teknikker. Der findes teoretiske bypass til de forskellige teknikker, men ved at aktivere dem ødelægger man (næsten) alle gamle exploits og gør nogle fremtidige exploits ikke virkende.

Ubrugelig kode? Næppe, men et tegn på at man ikke aner hvad man taler om, hvis man kalder EMET/ROP Guard det.

P.S M$' penge gik også til andre ROP 'beskyttende' teknikker.

Hvis vi ser på den nuværende tittel og den originale tittel som XorpiZ oplyste så vil jeg da bestemt mene at den nuværende er den bedste.

Som #6 er inde på så var der 5 projekter der fik $50k fra MS.

EMET Kan iøvrigt godt anbefales. Der er en tech review uden nu. Det er version 3.5 der indeholder de 5 projekter der fik penge fra MS. Jeg kører selv med version 3.0 på min win7 maskine og har smidt 3.5 på en win8 maskine.

en form for angreb kaldet ’return oriented programming’ (ROP). Ved ROP rearrangerer hackeren forskellige stykker kode i hukommelsen til at skabe fjendtlig kode.

Den forklaring giver ikke ret meget mening. Jeg spekulerer på om forfatteren forsøgte på at beskrive en type bufferoverløb uden at forstå hvad der egentlig foregår.

Før i tiden var overløb i en buffer som er allokeret på stakken meget nemme at udnytte. Hvis man kan forårsage et bufferoverløb vil den fortsatte skrivning meget hurtigt nå til funktionens returadresse, og denne ville altid ligge samme antal bytes fra bufferen. Man kan altså overskrive returadressen med en vilkårlig værdi.

Dermed har man beskadiget kaldstakken og i stedet for at returnere til den kaldende funktion returneres til en adresse valgt af angriberen. Denne adresse ville typisk ligge inde i bufferen, som netop er blevet fyldt op med angriberens kode.

Der er metoder til at beskytte imod denne type angreb. Den vigtigste er at stakken ikke må være eksekverbar. Når der returneres vil CPUen opdage at adressen ikke tillader afvikling af koden, kontrollen overdrages til operativsystemet som lukker processen ned. Derudover kan angreb besværliggøres ved at gøre stakkens startadresse tilfældig. Så kan angriberen ikke forudsige præcist hvor hans kode vil ligge.

En metode til stadigvæk at udføre angreb med samme type sikkerhedshuller er at ikke længere selv lever koden i angrebet, men i stedet udnytte kode som allerede findes som f.eks. biblioteksfunktioner.

Angriberen kan overskrive returadressen med adressen på en biblioteksfunktion. Så vil denne biblioteksfunktion afvikles efter den sårbare funktion returnerer. Biblioteksfunktionen vil forvente at finde parametre på stakken i et område som angriberen også kan overskrive.

Når denne biblioteksfunktion returnerer vil der ikke være nogen korrekt adresse at returnere til, da den i princippet aldrig er blevet kaldt. Men det ved funktionen ikke, og den vil blot returnere til den adresse den finder på stakken. Det kan angriberen udnytte ved at allerede have udfyldt denne adresse med adressen på en anden biblioteksfunktion.

På denne måde kan angriberen faktisk udføre en sekvens af funktionskald uden på noget tidspunkt at have fået sin egen kode afviklet, og dermed ikke være begrænset af at stakken ikke er eksekverbar.

Hvis man kiggede på stakken med en debugger lige efter afslutningen på den sårbare kode ville man se en umulig sekvens af kald, hvor den sårbare funktion tilsyneladende er blevet kaldt af de funktioner, som angriberen vil anvende. (Dog har jeg set et eksempel på en off-by-one bug i en debugger som gjorde at den ikke kunne dekode sådan en umulig stak, da den ikke kunne håndtere en returadresse der pegede på starten af en funktion).

Hvis f.eks. et program har en main() funktion som kalder buggy() som igen kalder gets(), så vil stakken se således ud:

gets()
buggy()
main()

Da gets() er næsten umulig at bruge uden at introducere et bufferoverløb burde buggy() ikke have kaldt gets(), og hvis vi antager at buggy() bruger en buffer i sin egen stakframe som parameter til gets() og læser input kontrolleret af angriberen er der et sikkerhedshul.

Efter angriberen har udnyttet sikkerhedshullet og overskrevet en del af stakken ser den nu således ud:

gets()
buggy()
open()
write()
close()
execve()

Det ser ud som om execve() har kaldt close() osv. Denne sekvens af kald kunne aldrig forekomme. Det der vil ske på vej tilbage er at buggy() returnerer til starten af open() som så returnerer til starten af write() osv.

Metoden med at organisere en stak på sådan en umulig måde har også legitime anvendelser. Det er f.eks. en praktisk måde at initialiserer stakken til en ny tråd. Hvis f.eks. en tråd skal starte med at kalde thread_main() kunne stakken fra start af se således ud:

thread_main()
_exit()

Det ser ud som om _exit() har kaldt thread_main(), men i virkeligheden kan det ikke lade sig gøre. Formålet er at når thread_main() returnerer vil den returnere til starten af _exit() som afslutter tråden.

Angrib som udnytter stakken på ovenstående måde er der metoder til at beskytte imod. En af metoderne er at indlæse biblioteker på tilfældige adresser således at angriberen ikke ved hvilke adresser der skal lægges på stakken for at gennemføre angrebet.

En anden metode er at placere alle libraries i starten af den virtuelle hukommelse således at alle adresserne indeholder en NUL byte. Hvis overløbet sker med en NUL termineret streng kan man ikke konstruere en stak med adskillige NUL tegn vha. et bufferoverløb.

Disse metoder forhindrer ikke legitim brug af en konstrueret stak da den sker i kode som allerede findes i processen.

Æblemos (6) skrev:

Hele idéen med toolkit'et er at nemt, hurtigt og effektivt sikre sine programmer via diverse 'lindrende' teknikker. Der findes teoretiske bypass til de forskellige teknikker, men ved at aktivere dem ødelægger man (næsten) alle gamle exploits og gør nogle fremtidige exploits ikke virkende.

Det primære forsvar skal til enhver tid være at skrive koden uden fejl. Selvom det måske ikke er muligt i praksis at skrive kode helt uden fejl, så er det i hvert fald en teoretisk mulighed.

Alle de andre metoder til at beskytte sig er blot ekstra foranstaltninger. Det kaldes defence-in-depth.

Hvis det niveau som er det primære forsvar er umuligt at gøre sikkert, selv i teorien, så kan man godt snakke om en ubrugelig sikkerhedsmodel. Men, hvis der er tale om at nogle af de ekstra lag af beskyttelse i nogle tilfælde vil kunne omgås, så er de ikke ubrugelige.

Disse lag i sikkerheden bør aldrig nås, da det kun sker i tilfælde af sikkerhedshuller i laget ovenpå. Hvis man på nogen måde kan konstruere et sikkerhedshul, som beskyttelsen vil beskytte effektivt i mod udnyttelse af, så er beskyttelsen noget værd, også selvom der kunne være andre huller, som det ikke beskytter imod.

Dermed vil jeg mene at der er en god chance for at du har ret. Omend jeg ikke mener det vigtige er om exploitkoden skal skrives om. Det vigtige er at for nogle huller kan man måske slet ikke få exploitkoden til at virke igen.

Jeg kender hverken den konkrete beskyttelse eller omgåelse, så jeg ved ikke om man altid kan omgå beskyttelsen.

#8

Jeg har hørt om flash exploits der ikke virker på maskiner der kører med EMET. Men ja det er blot et lag i defence in depth

Jeg indrømmer at jeg ikke har særligt meget forstand på lige dette. Dog står der i kilden

Kilde skrev:

...ROP works by rearranging benign pieces of code already present in memory to form a malicious payload.

Hermed forstod jeg det som at hackeren på "en eller anden magisk" måde kunne flytte rundt på funktioner i hukommelsen og "sammensætte" sin egen malware dynamisk i "realtime". Det er som jeg kan høre forkert.

Jeg troede at bufferoverflow var at skrive en længere "streng" end der er allkoret plads til e.g. skrive en 2-byte streng hvor der kun er plads til eb 1-byte streng. Herefter kunne hackeren så afvikle koden i det hukommelsessegment, hvor den "ekstra" byte var skrevet. Her skal streng forstås værende int, float etc.

Min forklaring på buffer overflow er sikkert forkert og det er sikkert det, at kasperd skrev.

thimon (10) skrev:

Dog står der i kilden

Kilde skrev:

...ROP works by rearranging benign pieces of code already present in memory to form a malicious payload.

Jeg tror ikke forfatteren til den artikel har forstået, hvad der foregår.

thimon (10) skrev:

Hermed forstod jeg det som at hackeren på "en eller anden magisk" måde kunne flytte rundt på funktioner i hukommelsen og "sammensætte" sin egen malware dynamisk i "realtime".

Det er også det som kilden siger. Jeg tror bare kilden tager fejl.

thimon (10) skrev:

Jeg troede at bufferoverflow var at skrive en længere "streng" end der er allkoret plads til e.g. skrive en 2-byte streng hvor der kun er plads til eb 1-byte streng.

Det er korrekt. Hvordan man så kan udnytte det afhænger af, hvad der ligger efter bufferen. Stakken har traditionelt været nem at udnytte, men det er vanskeligere hvis stakken ikke er eksekverbar.

thimon (10) skrev:

Herefter kunne hackeren så afvikle koden i det hukommelsessegment, hvor den "ekstra" byte var skrevet.

Det er de færreste angreb som kan nøjes med en ekstra byte. Og det er ikke sådan at kode skrevet ud over slutningen på bufferen automatisk bliver afviklet. Det ville kræve at man fandt en buffer som lå sammen med kode, hvilket de aldrig gør i kode med bare et minimum af sikkerhed.

Hvis man sender egentlig kode som en del af angrebet bliver den kode som regel lagt i selve bufferen. Det som skrives ud over slutningen har blot til formål at få koden afviklet.

Hvis angreb udnytter en buffer på heapen i stedet for stakken er det helt andre datastrukturer man overskriver, og angrebsteknikkerne er meget anderledes. Jeg har engang set en artikel, som beviste at det kunne lade sig gøre. Den hed vist noget i retning af "smashing the heap for fun and profit".

Det var et ganske imponerende angreb fordi sikkerhedshullet ikke var et generelt bufferoverløb, men derimod kun gav mulighed for at skrive en enkelt NUL byte et sted efter bufferen. Og den originale byte ville blive skrevet tilbage inden den sårbare funktion returnerede.

Men mens denne NUL byte stod hvor den ikke burde kunne der blive allokeret hukommelse. Ved at beskadige malloc()s datastrukturer kunne allokeringen udnyttes til at lave mere korruption af heapen.

Resten af den artikel blev så teknisk at det gik hen over hovedet på mig.