"Mads Chr. Olesen" <MadsChrO@Yahoo.com> wrote in message
news:ajo0mo$md0$1@sunsite.dk...
> Hvordan ser et buffer overflow ud i windows,
Uha, det var et ret generelt spørgsmål :)
Jeg mener at det normalt kaldes "buffer overrun", og det er et ret
almindeligt sikkerhedshul i software til både Windows og Unix.
Under Windows vil det ofte ytre sig ved at der popper et vindue op med noget
i retning af "Access Violation" og "The memory could not be read/written".
Men lige så ofte vil der ikke være noget at se. Et program kan have et
"slumrende buffer overrun sikkerhedshul", som ikke viser sig ved normal brug
af programmet. Først når en ondsindet person sender bevidst manipuleret og
tilrettelagt data med henblik på at udnytte sikkerhedshullet, sker der
mærkelige ting.
Problemet skyldes som regel at man har et array, også kaldet en buffer, af
fast størrelse, og programmøren glemmer at checke at man ikke skriver ud
over den plads i hukommelsen som er afsat til denne buffer.
Eksempel i C:
void someFunction(struct UserData* data)
{
char buf[80];
/* ... */
strcpy(buf, data->str); /* UPS! */
}
Problemet skyldes at læsning/skrivning til sådan en buffer, buf[80], ikke
bliver checket for "overrun" i C og C++, som er (blandt) de mest populære
sprog til Windows-programmering, fordi programmet så vil køre langsommere.
Når en cracker opdager ovenstående sikkerhedshul i et program (det kan man
opdage uden at have sourcekoden til programmet), så laver han en specielt
sammensat UserData besked og sender til programmet. Enten over nettet, i en
email, eller lægger det på en hjemmeside - mulighederne er utallige, og
afhænger af hvad slags program der er tale om. Når så denne UserData bliver
kopieret ind i 'buf', og fylder meget mere end de 80 bytes der er afsat, så
kan der ske hvadsomhelst - programmets C-stak bliver overskrevet med noget
som crackeren bestemmer over.
Mange crackere synes det er sejt at sammenbrygge sådan en UserData, der gør
lige hvad de vil have. Det er det måske også... "lidt"...
. Men det
ændrer ikke ved at crackeren bør få skudt knæskallerne af og/eller hænges op
i nosserne
. Det er *ikke* en undskyldning at man vil "bevise" at
systemerne er usikre - det *ved* vi godt!
Samme straf er passende til firmaer der har så travlt, at de udgiver
programmer med ovenstående problem.
> og hvordan løser man det?
Som programmør: Passer på med ting som strcpy, memcpy, sprintf, og andre
"farlige funktioner", hvor man kan komme til at kopiere eller skrive ting
ind et sted hvor der ikke er plads til det. Hvis man programmerer i C++, bør
man bruge de mere højniveau-ting som std::vector, og std::string, der er en
hel del sikrere i brug.
Som bruger: vi har nok desværre tabt. Der er ikke meget vi kan stille op.
Det vigtigste er at holde kritiske programmer (browser, email-klient, osv.)
opdateret med nyeste sikkerhedspatches.
Mvh. Bjarke