Dansk sikkerhedsfirma: Ny Windows-sårbarhed er ekstremt kritisk

Det danske it-sikkerhedsfirma Secunia kalder den nye Windows-sårbarhed noget af det værste, man kan løbe ind i.

En ny sårbarhed i flere versioner af Windows er så alvorlig, at det danske it-sikkerhedsfirma Secunia har klistret betegnelsen 'ekstremt kritisk' på den.

Det fortæller teknisk direktør i Secunia, Thomas Kristensen, om sårbarheden i Windows Graphics Rendering Engine, som Microsoft endnu ikke har patchet. Dermed er der tale om en 0-dagssårbarhed.

Læs også: Thumbnails slår huller i Windows XP, Vista og Server

»Der er et exploit ude og samtidig ingen patch tilgængelig mod sårbarheden. Det er noget af det værste, du kan løbe ind i,« siger Thomas Kristensen.

Sårbarheden kan udnyttes via fjernadgang til at skabe et stack-baseret buffer overflow på den angrebne Windows-pc.

Det sker for eksempel ved at få brugeren til at klikke på en thumbnail-billedfil, der er udformet på en måde, så Windows Graphics Rendering Engine fejl-parser den.

Dermed er det muligt for den angribende part at opnå samme rettigheder på pc'en som den bruger, der er logget ind og udsættes for exploitet. Det er naturligvis særligt alvorligt, hvis brugeren har administratorrettigheder.

Workaround: Ændring af filrettigheder

Et bredt udsnit af Windows-versioner fra XP og frem til Server 2008 er udsatte, mens Windows 7 og Server 2008 R2 går fri.

Microsoft har udsendt en vejledning til at begrænse rettighederne på den DLL-fil, shimgvw.dll, der indeholder sårbarheden, for at omgå problemet.

»Ændrer man filrettighederne, vil der være noget funktionalitet, som ikke fungerer korrekt, for eksempel visning af thumbnails. Men det er den eneste brugbare måde at omgå sårbarheden på i dag,« siger Thomas Kristensen.

Af samme grund opfordrer den tekniske direktør til at afprøve den omtalte 'workaround' på en maskine, hvor det kan tolereres at miste funktionaliteten.

Ifølge Thomas Kristensen er det svært at sige på nuværende tidspunkt, hvornår en patch kan ventes klar fra Microsoft.

»Vi har før set, at Microsoft er i stand til at reagere på et par uger og mindre. Men det kan også vare et par måneder, før en patch er klar,« siger han.

Det handler dels om, hvor meget sårbarheden bliver udnyttet i praksis og omtalt i medierne.

»Men hvis Microsoft kan se, at en patch vil påvirke for eksempel tredjepartsprogrammer negativt, så kan de være noget mere tilbageholdende med at udsende den,« siger Thomas Kristensen.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (12)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Lars Lundin

gcc har en option, -fstack-protector-all, som gør at et stack-baseret overflow ikke kan udnyttes til eksekvering af arbitrær kode (men istedet "kun" til at få det sårbare program til at stoppe, altså et DoS).

Under Ubuntu fra v. 6.10 (dvs. de sidste 4 år) er alle programmer per default oversat med -fstack-protector-all.

Har Windows ikke noget lignende ?

  • 0
  • 0
Jonas Høgh

Har Windows ikke noget lignende ?

Jo, Microsofts compiler understøtter stack canaries, og bruger dem som default.

Desuden har Windows understøttet Data Execution Prevention og Address Space Layout Randomization i en del år.

Desværre er det jo ikke ensbetydende med at alle programmer er beskyttet, man bygger jo ikke lige hele software-stakken fra scratch når det ikke er open source :-)

  • 0
  • 0
Jonas Høgh

Hej Peter,

Det var ikke en kommentar vedrørende den konkrete sårbarhed, den vil jeg ikke gøre mig til ekspert i :-)

Det jeg prøvede at sige var, at når der ikke sidder en central maintainer, der kan compile hele OS + applikationer, som der fx gør i Ubuntu, så tager det en del år, før man kan gøre sig forhåbning om, at størstedelen af den kode man kører på sin Windows maskine rent faktisk er beskyttet af disse tiltag. Det skyldes at de enten skal compiles ind af en lokal person, eller ikke er slået til som default overalt pga bagudkompatibilietetsproblemer.

  • 0
  • 0
Peter Kruse

Hej Jonas,

Korrekt. Mit indspark var også mere møntet på at denne sårbarhed ikke umiddelbart har nemt ved at omgå ASLR der er implementeret på mange nyere versioner af Windows. Derudover kan jeg såmænd ikke være andet end enig.

Venligst
Peter

  • 0
  • 0
Lars Lundin

Mit indspark var også mere møntet på at denne sårbarhed ikke umiddelbart har nemt ved at omgå ASLR der er implementeret på mange nyere versioner af Windows.

For nogle år siden havde jeg lejlighed til at undersøge hvor effektivt ASLR virker under Linux, hvor det kaldes "Virtual Address Space Randomization". Det virker ved at et antal af de mindst betydende bits i stack-pointeren vælges tilfældigt, hver gang en funktion kaldes. Man kan nemt skrive et lille program, der kalder en function et antal gange, og hver gang ser på værdien af SP, og på den måde få en ide om hvor mange bits det drejer sig om. En exploit-kode, som har mulighed for at skrive en besked tilbage til sin bruger kan derfor starte med at advare om at der er ASLR og hvor mange forsøg man må forvente der skal til for at udnytte sårbarheden.

På 32-bit systemer så jeg at det var de 23 mindst betydende bits der er tilfældige (svarende til 8MB), mens på 64-bit systemer så jeg at det var de mindst betydende 32bit (svarende til 4GB).

Hvis forsøget på at udnytte et stack-overflow tillader at man kan definere en environment variabel, så kan man (under Linux) altid lave en exploit-kode med mindst 126kB nop's svarende til ca. 17 bit. Hvis den buffer der kan "overflowes" er større end 126kB, så kan forsøget dække tilsvarende flere bits.

På et 32-bit system er der derfor max kun ca. 6 bit, som forsøget på at udnytte sårbarheden skal ramme. Dvs. der skal af størrelsesorden 64 forsøg (eller mindre hvis det er en stor buffer der er sårbar) til at udnytte et stack-overflow på et 32-bit (Linux) system, selv med ASLR.

På et 64-bit system er antallet drastisk større, af størrelsesordenen 32-17 = 15bit, dvs. der skal af størrelsesorden 32k forsøg til at udnytte et buffer-overflow, selv med ASLR.

Med mindre det tager lang at nå det sårbare punkt i eksekveringen, vil jeg derfor påstå at ASLR ikke er særligt effektivt, specielt ikke på 32-bit systemer.

  • 0
  • 0
Robert Larsen

Det virker ved at et antal af de mindst betydende bits i stack-pointeren vælges tilfældigt, hver gang en funktion kaldes.

Det er jeg ret sikker på ikke passer. Stakken bliver allokeret én gang når processen startes op, og adressen bliver tilfældigt valgt, men ændres derefter ikke.

Iøvrigt bliver andre dele af hukommelsen også randomized (lænkede biblioteker og så'n, men ikke programmets egen kode).

Hver gang programmet eksekveres er det altså med forskelligt memory layout, men det ændres ikke midt i eksekveringen.

Dette program:

#include <stdio.h>  
   
void function() {  
    int a;  
    printf("a: %p\n", &a);  
}  
   
int main (int argc, char ** argv) {  
    int i;  
    for (i = 0; i < 10; i++) {  
        function();  
    }  
    return 0;  
}

Giver følgende output:

robert-desktop:~ $ ./test   
a: 0x7fffc607c93c  
a: 0x7fffc607c93c  
a: 0x7fffc607c93c  
a: 0x7fffc607c93c  
a: 0x7fffc607c93c  
a: 0x7fffc607c93c  
a: 0x7fffc607c93c  
a: 0x7fffc607c93c  
a: 0x7fffc607c93c  
a: 0x7fffc607c93c  
robert-desktop:~ $ ./test   
a: 0x7fffad924e8c  
a: 0x7fffad924e8c  
a: 0x7fffad924e8c  
a: 0x7fffad924e8c  
a: 0x7fffad924e8c  
a: 0x7fffad924e8c  
a: 0x7fffad924e8c  
a: 0x7fffad924e8c  
a: 0x7fffad924e8c  
a: 0x7fffad924e8c  
robert-desktop:~ $ 

Det er iøvrigt PaX patchen som gør dette under Linux: http://en.wikipedia.org/wiki/PaX

  • 0
  • 0
Robert Larsen

Forresten findes der langt bedre måder at omgå ASLR end bruteforce.

Et par af dem kan læses i denne reference: http://netsec.cs.northwestern.edu/media/readings/defeating_aslr.pdf

Derudover giver denne også et par muligheder: http://www.blackhat.com/presentations/bh-usa-08/Shacham/BH_US_08_Shacham...
...udover også at omgå DEP.

Stack cookies er lidt sværere (efter min mening) men med et format string exploit eller andet kan man nok læse værdien af kagen.

  • 0
  • 0
Lars Lundin

"Det virker ved at et antal af de mindst betydende bits i stack-pointeren vælges tilfældigt, hver gang en funktion kaldes."

Det er jeg ret sikker på ikke passer. Stakken bliver allokeret én gang når processen startes op, og adressen bliver tilfældigt valgt, men ændres derefter ikke.

Det giver jeg dig ret i, tak for den væsentlige rettelse.

Det var udfaldsrummet i dette tilfældige valg jeg kiggede på. Effekten ifbm. stack smashing er at stack-pointeren for et givet funktionskald varierer (inden for det givne udfaldsrum) for forskellige processer.

  • 0
  • 0
Robert Larsen

Det er korrekt. En af mulighederne er så istedet for at returnere til en hardcodet adresse, så at finde adressen et andet sted...måske i EAX registeret og så returnere til en fast adresse på en 'jmp EAX'/'call EAX' instruktion i en region som ikke er tilfældig...text segmentet f.eks.

Men så kommer DEP og ødelægger det hele, fordi processoren ikke vil eksekvere de instruktioner, som vi har lagt på stakken. Det kan man så komme udenom med return-into-libc eller return oriented programming...men det bliver sværere med stack cookies :-)
De kan så muligvis klares med format strings eller andre sårbarheder, som lader os læse hukommelsen.

Det er et interessant kapløb.

  • 0
  • 0
Log ind eller Opret konto for at kommentere