Format String Problemer


  Share  
|


Formatstrengen problemene er en av de få virkelig nye angrep til overflaten de siste årene. En av de første omtaler av formatstrengen feil ble den 23. juni 2000, i et innlegg av Lamagra Argamal (www.securityfocus.com/archive/1/66842); Pascal Bouchareine tydeligere forklart dem nesten en måned senere (www.securityfocus.com/archive/1/70552). Et tidligere innlegg av Mark Slemko (www.securityfocus.com/archive/1/10383) Noterte grunnleggende problemet, men savnet evne til formatstrengen feil å skrive minne.

Som med mange sikkerhetsproblemer, er det rot årsak til formatstrengen bugs tillitsfullt bruker-leverte innspill uten godkjenningen. I C / C + +, kan formatstrengen bugs brukes til å skrive til minne vilkårlige steder, og de farligste aspektet er at dette kan skje uten tukling med tilstøtende minneblokker. Dette finkornede mulighet tillater en angriper å omgå stabelen beskyttelse, og selv modifisere veldig små porsjoner av hukommelse. Problemet kan også oppstå når formatstrenger leses fra en ikke-klarert plassering angriperen kontrollerer. Dette siste aspektet av problemet synes å være mer utbredt på UNIX og Linux systemer. På Windows-systemer, blir søknaden streng tabeller vanligvis holdes innenfor den kjørbare eller ressurs Dynamic Link Libraries (DLLs). Hvis en angriper kan omskrive største kjørbare eller ressursen DLL-filer, kan angriperen utføre mange en mer direkte angrep enn formatstrengen bugs.

Selv om du ikke gjøre med C / C + +, kan formatstrengen angrep fortsatt føre til store problemer. Det mest åpenbare er at brukere kan bli lurt, men under visse forhold, kan en angriper også starte cross-site scripting eller SQL-injeksjon angrep. Disse kan brukes til å ødelegge eller forandre data i tillegg.

Berørte språk

Den mest sterkt påvirket språket er C / C + +. Et vellykket angrep kan føre umiddelbart til kjøring av vilkårlig kode, og til avsløring av informasjon. Andre språk vil vanligvis ikke tillate kjøring av vilkårlig kode, men andre typer angrep er mulig, som vi tidligere notat. Perl er ikke direkte utsatt for byggebransjen blir gitt av brukerundersøkelser, men det kan være sårbare dersom formatstrenger blir lest inn fra forfalske data.

The Sin Forklart

Formatere data for visning eller lagring kan være en litt vanskelig oppgave. Dermed mange programmeringsspråk omfatte rutiner for enkelt å reformatere data. I de fleste språk, er formateringsinformasjon beskrives ved hjelp av en slags streng, kalt formatstrengen. Formatet strengen er egentlig definert ved hjelp av begrensede data processing språk som er designet for å gjøre det enkelt å beskrive output formater. Men mange utviklere lage en enkel feil-de bruker data fra ikke-klarerte brukere som formatstrengen. Som et resultat, kan angriperne skrive strenger i databehandling språket for å skape mange problemer.

Utformingen av C / C + + gjør dette spesielt farlig: C / C + + 's design gjør det vanskeligere å oppdage formatstrengen problemer og formatstrenger inneholde noen særlig farlig kommandoer (spesielt% n) som ikke finnes i noen andre språk' formatstrengen språk.

I C / C + +, kan en funksjon bli erklært for å ta et varierende antall argumenter ved å angi en ellipse (...) som den siste (eller eneste) argument. Problemet er at funksjonen blir kalt har ingen måte å vite hvor mange argumenter blir bestått i. Den vanligste sett med funksjoner for å ta variabel lengde argumenter er printf familien: printf, sprintf, snprintf, fprintf, vprintf, og så på. Bred karakter funksjoner som utfører samme funksjon har samme problem. La oss ta en titt på en illustrasjon:

# include

int main (int argc, char * argv [])
(
if (argc> 1)
printf (argv [1]);

return 0;
)

Ganske enkel ting. Nå la oss se på hva som kan gå galt. Programmerer forventer at brukeren må taste inn noe benign, for eksempel Hello World. Hvis du gir den en prøve, får du tilbake Hello World. Nå skal vi endre input litt-prøve% x% x. På en Windows XP-system som bruker standard kommandolinja (cmd.exe), vil du nå få følgende:

E: \ prosjekter \ 19_sins \ format_bug> format_bug.exe "% x% x"
12ffc0 4011e5

Merk at hvis du kjører et annet operativsystem, eller bruker en annen kommandolinje tolk, må du kanskje gjøre noen endringer for å få dette nøyaktig streng matet inn i programmet, og resultatene vil være forskjellig. For brukervennlighet, kan du sette argumentene i et shell script eller satsvis fil.

Hva skjedde? Den printf-funksjonen tok en inngang streng som forårsaket det å forvente to argumenter for å bli skjøvet ut stabelen før kalle funksjonen. Den% x specifiers aktivert deg å lese stabelen, fire byte av gangen, så langt som du ønsker. Det er ikke vanskelig å forestille seg at hvis du hadde en mer kompleks funksjon som er lagret en hemmelig i en stabel variabel, angriperen da kunne lese det hemmelige. Utgangen her er adressen av stabelen sted (0x12ffc0), etterfulgt av koden plasseringen som main ()-funksjonen vil komme tilbake til. Som du kan forestille deg, begge disse er svært viktige biter av informasjon som blir lekket til en angriper.

Du kan nå lurer på akkurat hvor angriperen bruker en formatstrengen feil å skrive minne. En av de minst brukte formatet byggebransjen er% n, som skriver antall tegn som burde vært skrevet så langt inn adressen til variabelen du ga som tilsvarende argument. Her ser du hvordan det skal brukes:

unsigned int bytes;
printf ( "% s% n \ n", argv [1], og bytes);
printf ( "Din inngang var% d tegn \ n, bytes");

Utgangen vil være:

E: \ prosjekter \ 19_sins \ format_bug> format_bug2.exe "Noen tilfeldig input"

Noen tilfeldige innspill

Ditt innspill var 17 tegn

På en plattform med fire byte heltall, de% n Specifier skal skrive fire bytes på en gang, og% hn vil skrive to bytes. Nå angripere bare å finne ut hvordan du kan få adressen de ønsker i riktig posisjon i bunken, og justere feltet bredden specifiers til antall bytes skrevet er hva de ønsker.

For nå kan vi bare anta at hvis du lar angriperne å kontrollere formatstreng en C / C + +-programmet, er det et spørsmål om tid før de finner ut hvordan du kan få deg til å kjøre koden sin. En spesielt ubehagelig aspekt ved denne type angrep, er at før du starter angrepet, kan de sonden bunken og korrekt angrepet på fly. Faktisk første gang forfatteren demonstrerte dette angrepet offentlig, brukte han en annen kommandolinje tolk enn han hadde brukt til å opprette demonstrasjon, og det fungerte ikke. På grunn av den unike fleksibiliteten i dette angrepet, ble det mulig å løse problemet og utnytte prøven søknaden med publikum ser på.

De fleste andre språk støtter ikke tilsvarer en% n format Specifier, og de er ikke direkte utsatt for enkel utførelse av angriperen-leverte kode, men du kan fortsatt støte på problemer. Det finnes andre, mer kompliserte varianter på dette angrepet som andre språk, er sårbare for. Dersom angripere kan angi en formatstrengen for utdata til en loggfil eller databasen, kan de forårsake uriktige eller villedende logger. I tillegg kan programmet lese loggene kan vurdere dem klarerte inngang, og når denne forutsetningen er brutt, svakheter i at programmet parseren kan føre til kjøring av vilkårlig kode. Et beslektet problem er innstøping kontroll tegn i loggfiler-backspaces kan brukes til å slette ting; linje terminatorer kan Beskytt eller eliminere angriperens spor.

Dette bør gå uten å si, men hvis en angriper kan spesifisere formatstrengen matet til scanf eller lignende funksjoner, er katastrofe på vei.

Sinful C / C + +

I motsetning til mange andre feilene vi vil undersøke, er dette et ganske lett å oppdage som en kode feil. Det er veldig enkelt:

printf (user_input);
er feil, og

printf ( "% s", user_input);
er riktig.

En variant på problemet at mange programmerere forsømmelse er at det ikke er tilstrekkelig til å gjøre dette riktig bare en gang. Det finnes en rekke felles kode konstruerer der du kan bruke sprintf å plassere en formatert streng i en buffer, og så gli opp og gjør dette:

fprintf (stdout, err_msg);
Angriperen da har bare å utforme innspill slik at formatet byggebransjen er flyktet, og i de fleste tilfeller er dette en mye lettere å utnytte versjon fordi err_msg bufferen ofte vil bli tildelt på stakken. Når angripere klarer å gå tilbake opp stabelen, vil de kunne kontrollere det stedet som er skrevet med brukerundersøkelser.

Relaterte Sins

Selv de mest opplagte angrepet er relatert til en kode feil, er det en vanlig praksis å sette programmet strenger i eksterne filer for internasjonalisering formål. Hvis søknaden har syndet ved å unnlate å beskytte filen på riktig måte, da en angriper kan levere formatstrenger grunn av mangel på skikkelig filtilgang.

En annen relatert synd ikke klarer å riktig validere brukerundersøkelser. På noen systemer, angir en miljøvariabelen den nasjonale innstillingen informasjon, og den nasjonale innstillingen i sin tur avgjør katalogen der språkspesifikke filer vil bli funnet. På noen systemer kan angriperen selv føre til at programmet skal se ut i vilkårlig kataloger.

Spotting the Sin Mønster

Ethvert program som tar brukerundersøkelser og sender den til en formatering funksjon er potensielt i fare. En meget vanlig forekomst av denne synden skjer i forbindelse med programmer som logger brukerens input. I tillegg kan enkelte funksjoner gjennomføre formatering internt.

Spotting i Sin Under kode gjennomgang

I C / C + +, se etter funksjoner fra printf familien. Problemer med å se etter er

printf (user_input); 
fprintf (stdout, user_input);

Hvis du ser en funksjon som ser slik ut:

fprintf (stdout, msg_format, Arg1, arg2);

Deretter må du kontrollere hvor strengen refereres msg_format lagres og hvor godt det er beskyttet.

Det er mange andre system samtaler og APIer som også er sårbare-syslog er ett eksempel. Hver gang du ser en funksjon definisjon som inkluderer ... i argumentet listen, du ser på noe som sannsynligvis vil være et problem.

Mange kildekoden skannere, selv den leksikalske seg som rotter og flawfinder, kan oppdage dette. Det er enda PScan (www.striker.ottawa.on.ca/ ~ Aland / pscan /), Som ble designet spesielt for dette.

Det er også møte verktøy som kan bygges inn i samlealbum prosessen. For eksempel er det Crispin Cowan's FormatGuard: http://lists.nas.nasa.gov/archives/ext/linux-security-audit/2001/05/msg00030.html

Testing Teknikker for å finne Sin

Pass formatering byggebransjen i programmet, og se om heksadesimale verdier returneres. For eksempel, hvis du har et program som forventer et filnavn og returnerer en feilmelding som inneholder inngang når filen ikke kan finnes, og deretter prøve å gi den filnavn som NotLikely% x% x.txt. Hvis du får en feilmelding langs linjene av "NotLikely12fd234104587.txt ikke finnes", da du nettopp har funnet et format svakhet.

Dette er åpenbart noe språkavhengig; du skal passere i formateringen byggebransjen som brukes av gjennomføringen språket du bruker minst. Men siden mange språk kjøre ganger er implementert i C / C + +, vil du være klokt å også send i C / C + + formatering streng kommandoer for å oppdage tilfeller der den underliggende biblioteket har en farlig sårbarhet.

Merk at hvis programmet er webbasert og ekko din brukerundersøkelser tilbake til deg, en annen bekymring ville være cross-site scripting-angrep

Eksempel Sins

Følgende oppføringer i Common Vulnerabilities and Exposures (CVE) på http:// cve.mitre.org er eksempler på SQL-injeksjon. Av de 188 CVE oppføringer som refererer formatstrenger, dette er bare et utvalg.

CVE-2000-0573

Fra CVE beskrivelse: "The lreply funksjonen i Wu-ftpd 2.6.0 og tidligere ikke skikkelig rens en uklarert formatstrengen, noe som gjør at eksterne angripere å kjøre vilkårlige kommandoer via nettstedet EXEC kommandoen.

Dette er den første offentlig kjent utnytte et format string bug. Tittelen på BUGTRAQ innlegget understreker alvorligheten av problemet: "Tilby * eksterne * rot siden minst 1994."

CVE-2000-0844

Fra CVE beskrivelse: "Noen funksjoner som implementerer locale delsystemet på UNIX ikke skikkelig rens user-injisert formatstrenger, som gir lokale angripere å kjøre vilkårlige kommandoer via funksjoner som gettext og catopen."

Den fullstendige teksten i det opprinnelige rådgivende kan finnes på www.securityfocus.com/archive/1/80154, og dette problemet er spesielt interessant fordi det påvirker core system APIs for de fleste UNIX-varianter (inkludert Linux), med unntak av BSD-varianter på grunn av at NLSPATH variabelen ignoreres for privilegerte suid søknad i BSD. Denne veiledningen, som mange CORE SDI veiledninger er spesielt godt skrevet og informativ, og gir en svært grundig forklaring på den generelle problemet

Redemption Steps

Det første trinnet er pass aldri bruker input direkte til en formatering funksjon, og også være sikker på å gjøre dette på alle nivåer i håndtering formatert utgang. Som en ekstra oppmerksom, formatering funksjoner har betydelig overhead. Se på kilde for _output hvis du er interessert, det kan være praktisk å skrive:

fprintf (stdout, buf);

De foregående kodelinje er ikke bare farlig, men den bruker mye ekstra CPU-sykluser.

Den andre steget å ta, er å sikre at formatstrenger søknaden din bruker er bare leses fra klarerte steder, og at veier til strengene ikke kan kontrolleres av angriperen. Hvis du skriver kode for UNIX og Linux, etter eksempel på BSD-variantene og å ignorere NLSPATH variabel, som kan brukes til å angi filen brukes til lokaliserte meldinger, kan gi noen dyptgående.

C / C + + Redemption

Det er ikke mye mer til det enn dette:

printf ( "% s", user_input);

Ekstra Defensive Tiltak

Sjekk og begrense locale til gyldige verdier. (For mer informasjon, se David Wheeler's "Write It Secure: Format strykere og Locale Filtering" oppført under "Andre ressurser" nedenfor). Ikke bruk printf-familien av funksjonene hvis du kan unngå det. For eksempel, hvis du bruker C + +, bruk stream operatører i stedet:

# include  
//... 
std:: cout <<user_input 
//...

Andre ressurser

en artikkel presentert av Hendra Fang

Share  
© 2005-2010 E-articles.info All Rights Reserved - Terms and conditions