Buffer overflow

I edb-sikkerhed og programmering, en buffer overflow, eller bufferoverløb, er en anomali, hvor et program, mens du skriver data til en buffer, overskridelser bufferens grænsen og overskriver tilstødende hukommelse. Dette er et særligt tilfælde af overtrædelse af hukommelse sikkerhed.

Bufferoverløb kan udløses af input, der er designet til at udføre kode, eller ændre den måde, programmet fungerer. Dette kan resultere i uregelmæssig program adfærd, herunder hukommelse adgang fejl, forkerte resultater, et nedbrud eller en overtrædelse af systemets sikkerhed. De er dermed basis af mange software sårbarheder og kan skadeligt udnyttes.

Programmeringssprog ofte forbundet med bufferoverløb omfatter C og C ++, som giver ingen indbygget beskyttelse mod adgang til eller overskrive data i nogen del af hukommelsen og ikke automatisk kontrollere, at data skrevet til en array er inden for grænserne af denne array. Kontrol af grænser kan forhindre bufferoverløb.

Teknisk beskrivelse

En buffer overflow opstår, når data skrevet til en buffer korrumperer også dataværdier i hukommelsesadresser støder op til den destination bufferen som følge af utilstrækkelige kontrol af grænser. Dette kan forekomme, når du kopierer data fra en buffer til en anden uden først at kontrollere, at dataene passer inden destinationen buffer.

Eksempel

I det følgende eksempel, et program har data to punkter, der støder op til hinanden i hukommelsen: en 8-byte-lang streng buffer, A, og en to-byte big-endian heltal, B.

I første omgang A indeholder intet andet end nul bytes, og B indeholder nummeret 1979.

Nu forsøger programmet at gemme null-afsluttet streng med ASCII koder i en buffer.

 er 9 tegn lang og koder til 10 bytes, herunder terminatoren, men A kan tage kun 8 bytes. Ved ikke at kontrollere længden af ​​strengen, overskriver også værdien af ​​B:

B værdi er nu blevet utilsigtet erstattet af en række dannet af en del af tegnstrengen. I dette eksempel "e" efterfulgt af et nul-byte ville blive 25.856.

Skrivning af data forbi slutningen af ​​allokerede hukommelse kan undertiden påvises ved operativsystemet til at generere en segementeringsfejl fejl, der afslutter processen.

Udnyttelse

De teknikker til at udnytte en buffer overflow sårbarhed varierer fra arkitektur ved operativsystemet og hukommelse region. For eksempel, udnyttelse på den bunke, adskiller sig markant fra udnyttelse på opkald stakken.

Stack-baserede udbytning

En teknisk tilbøjelig bruger kan udnytte stakbaserede bufferoverløb at manipulere programmet til deres fordel i en af ​​flere måder:

  • ved at overskrive en lokal variabel, der er nær buffer i hukommelsen på stakken for at ændre adfærd af programmet - som kan gavne angriberen.
  • ved at overskrive afsenderadressen i en stak ramme. Når funktionen returnerer, vil udførelse genoptages på afsenderadressen som angivet af hackeren, som regel en brugervenlig indgang fyldt buffer.
  • ved at overskrive en funktion pointer eller undtagelse handleren, som efterfølgende henrettet
  • ved at overskrive en parameter i en anden stakramme eller en ikke-lokal adresse pegede i den aktuelle stabel kontekst

Med en metode kaldet "trampolinspring", hvis adressen på den bruger-leverede data er ukendt, men placeringen er gemt i et register, så afsenderadressen kan overskrives med adressen på en opcode som vil medføre udførelse at springe til bruger leverede data. Hvis placeringen er lagret i et register R, derefter et hop til den placering, der indeholder opcode for et spring R, R ringe eller lignende instruktion, vil forårsage udførelse af brugerleverede data. Placeringerne af egnede opcodes, eller bytes i hukommelsen, kan findes i DLL eller i eksekverbare selv. Adressen på opcode typisk kan imidlertid ikke indeholde null tegn og placeringen af ​​disse opcodes kan variere mellem anvendelser og versioner af operativsystemet. Metasploit Project, for eksempel, vedligeholder en database over egnede opcodes, men kun dem, der findes i Windows-operativsystem-system notering.

Stack-baserede bufferoverløb ikke at forveksle med stakken overløb.

Bemærk også, at disse sårbarheder normalt opdaget ved hjælp af en fuzzer.

Udnyttelse Heap-baserede

En buffer overflow forekommer i bunke dataområde er omtalt som en bunke overløb og er udnyttes på en måde anderledes end stack-baserede overløb. Hukommelse på bunke dynamisk tildeles af ansøgning på run-time, og indeholder typisk program data. Udnyttelse udføres ved at ødelægge disse data på bestemte måder at få programmet til at overskrive interne strukturer såsom forbundne liste pointere. Den kanoniske heap overflow teknik overskriver dynamisk hukommelse tildeling kobling og bruger den resulterende pointer udveksling at overskrive et program funktion pointer.

Microsofts GDI + sårbarhed i håndtering JPEG er et eksempel på den fare, en bunke overløb kan præsentere.

Barrierer for udnyttelse

Manipulation af bufferen, som opstår, før den læst eller henrettet, kan føre til svigt af en udnyttelsestilladelse forsøg. Disse manipulationer kan afbøde truslen om udnyttelse, men kan ikke gøre det umuligt. Manipulationer kunne omfatte konvertering til store eller små bogstaver, fjernelse af metategn og filtrering ud af ikke-alfanumeriske strenge. Der findes imidlertid teknikker til at omgå disse filtre og manipulationer; alfanumerisk kode, polymorf kode, selv-modificerende kode og vende tilbage-til-libc angreb. De samme fremgangsmåder kan anvendes for at undgå afsløring af intrusion detection systemer. I nogle tilfælde, herunder hvor kode omdannes til Unicode, har truslen om sårbarheden blevet fordrejet af disclosers som kun Denial of Service når de i virkeligheden fjernbetjeningen udførelse af vilkårlig kode er mulig.

Praktiske for udnyttelse

I den virkelige verden udnytter der er en række udfordringer, som skal overvindes for exploits til at fungere pålideligt. Disse faktorer omfatter null bytes i adresser, variation i placeringen af ​​shellcode, forskelle mellem miljøer og forskellige modforanstaltninger i drift.

NOP sled teknik

En NOP-slæde er den ældste og mest kendte teknik til succes at udnytte en stak buffer overflow. Den løser problemet med at finde den nøjagtige adresse på bufferen ved effektivt at øge størrelsen af ​​målområdet. For at gøre dette, er meget større dele af stablen beskadiget med nogen-op maskine instruktion. Ved afslutningen af ​​angriberen-leverede data, efter de ikke-op instruktioner angriberen placerer instrukser om at udføre en relativ springe til toppen af ​​bufferen hvor shellcode er placeret. Denne samling af ikke-OPS er benævnt "NOP-slæde", fordi hvis returadressen overskrives med enhver adresse i no-op-regionen af ​​bufferen vil "slide" ned ingen-OPS, indtil det er omdirigeret til den faktiske ondsindet kode fra springet i slutningen. Denne teknik kræver angriberen at gætte, hvor på stakken NOP-slæden er i stedet for den forholdsvis lille shellcode.

På grund af populariteten af ​​denne teknik, vil mange leverandører af intrusion prevention systemer søge efter dette mønster af no-op maskininstruktioner i et forsøg på at påvise shellcode i brug. Det er vigtigt at bemærke, at en NOP-slæde ikke nødvendigvis kun indeholde traditionelle nej-op maskine instruktioner; en instruks, der ikke korrupte maskinen tilstand til et punkt, hvor shellcode vil ikke køre kan bruges i stedet for hardware bistået nogen-op. Som et resultat er det blevet almindelig praksis for at udnytte forfattere til at komponere nej-op slæde med tilfældigt udvalgte instruktioner, som vil have nogen reel effekt på shellcode udførelse.

Selv om denne fremgangsmåde i høj grad forbedrer chancerne for, at et angreb vil være vellykket, er det ikke uden problemer. Udnytter ved hjælp af denne teknik, stadig må stole på en vis mængde af held, at de vil gætte forskydninger på stakken, der er inden for NOP-slæde region. En forkert gæt vil normalt resultere i målprogram nedbrud og kunne advare systemadministratoren til hackerens aktiviteter. Et andet problem er, at NOP-slæden kræver en meget større mængde hukommelse til at holde en NOP-slæde store nok til at være til nogen nytte. Dette kan være et problem, når den tildelte størrelsen af ​​det berørte buffer er for lille og aktuelle dybde stakken er lavvandet. Trods sine problemer, NOP-slæden er ofte den eneste metode, der vil arbejde for en given platform, miljø eller situation; som sådan er det stadig en vigtig teknik.

Springet til at løse opbevares i et register teknik

Den "spring til at registrere" teknik gør det muligt for pålidelig udnyttelse af stakken bufferoverløb uden behov for ekstra plads til en NOP-slæde og uden at skulle gætte stack forskydninger. Strategien er at overskrive afkastet pointer med noget, der vil få programmet til at springe til en kendt pointer lagret i et register, som peger på den kontrollerede buffer og dermed shellcode. For eksempel, hvis register A indeholder en pointer til starten af ​​en buffer så enhver hop eller ring tage at registrere som en operand kan bruges til at få kontrol over strømmen af ​​udførelsen.

I praksis et program kan ikke med vilje indeholde instruktioner til at springe til et bestemt register. Den traditionelle løsning er at finde en utilsigtet forekomst af en egnet opcode på et fast sted eller andet sted inden programhukommelsen. I figur E til venstre kan du se et eksempel på en sådan utilsigtet forekomst af i386 instruktion. Den opcode for denne instruktion er. Denne to byte sekvens kan findes på en én byte forskudt fra starten af ​​instruktionen på adressen. Hvis en angriber overskriver programmet returadresse med denne adresse vil programmet hoppe til først, fortolke opcode som instruktion, og vil derefter springe til toppen af ​​stakken og udføre hackerens kode.

Når denne teknik er det muligt at sværhedsgraden af ​​sårbarheden øges betydeligt. Dette skyldes udnyttelse vil fungere pålideligt nok til at automatisere et angreb med en virtuel garanti for succes, når det køres. Af denne grund er dette den teknik mest almindeligt anvendte i Internet orme, der udnytter stackbufferoverløb svagheder.

Denne metode giver også shellcode skal placeres efter overskrevet returadresse på Windows-platformen. Da eksekverbare meste er baseret på adressen, og x86 er lidt Endian arkitektur, skal den sidste byte i afsenderadressen være en null, som afslutter bufferen kopiere og intet er skrevet ud over dette. Dette begrænser størrelsen af ​​shellcode til størrelsen af ​​bufferen, som kan være alt for restriktiv. DLL er placeret i høj hukommelse og så har adresser, der ikke indeholder null byte, så denne metode kan fjerne null byte fra overskrevet returadresse. Bruges på denne måde, er fremgangsmåden ofte omtales som "DLL trampolin".

Beskyttende modforanstaltninger

Forskellige teknikker er blevet anvendt til at afsløre eller forhindre bufferoverløb, med forskellige kompromiser. Den mest pålidelige måde at undgå eller forebygge buffer overflow er at bruge automatisk beskyttelse på sprogniveau. Denne form for beskyttelse kan imidlertid ikke anvendes på gamle kode, og ofte teknisk, business, eller kulturelle begrænsninger kræver en sårbar sprog. De følgende afsnit beskriver de valg og implementeringer rådighed.

Valg af programmeringssprog

Valget af programmeringssprog kan have en dybtgående effekt på forekomsten af ​​bufferoverløb. Fra 2008, blandt de mest populære sprog er C og dens afledte, C ++, med et stort system af software er blevet skrevet på disse sprog. C giver ingen indbygget beskyttelse mod adgang til eller overskrive data i nogen del af hukommelsen; Mere specifikt betyder det ikke kontrolleres, at data skrevet til en buffer er inden for grænserne af denne buffer. Standarden C ++ biblioteker giver mange måder på sikker buffermidler data, og C ++ 's Standard Template Library giver beholdere, der kan eventuelt udføre kontrol af grænser, hvis programmøren udtrykkeligt kræver kontrol, mens adgang til data. For eksempel, en 's medlem funktion udfører en bounds kontrol og kaster en undtagelse, hvis grænserne tjekke svigter. Men C ++ opfører sig ligesom C, hvis grænserne kontrollere ikke udtrykkeligt hedder. Teknikker til at undgå bufferoverløb findes også for C.

Mange andre programmeringssprog giver runtime kontrol og i nogle tilfælde endda kompilere-time kontrol, som kunne sende en advarsel eller hæve en undtagelse, når C eller C ++ ville overskrive data og fortsætte med at udføre yderligere instruktioner, indtil fejlagtige resultater opnås, som måske eller måske ikke medføre program til at gå ned. Eksempler på sådanne sprog omfatter Ada, Eiffel, Lisp, Modula-2, Smalltalk, OCaml og sådanne C-derivater som Cyclone, Rust og D. Java and.NET Framework bytecode miljøer også kræve kontrol af grænser på alle arrays. Næsten hver fortolket sprog vil beskytte mod bufferoverløb, signalering en veldefineret fejltilstand. Ofte, hvor et sprog giver nok typen oplysninger til at gøre kontrol af grænser en option leveres for at aktivere eller deaktivere den. Statisk kode analyse kan fjerne mange dynamiske bundne og type kontrol, men dårlige implementeringer og akavet tilfælde kan markant nedsætte ydeevnen. Software ingeniører skal nøje overveje de kompromiser for sikkerhed versus ydeevne omkostninger, når beslutningen om, hvilke sprog og compiler indstilling til at bruge.

Anvendelse af sikre biblioteker

Problemet med buffer overløb er almindelig i C og C ++ sprog, fordi de udsætter repræsentative oplysninger om buffere lave niveau som beholdere til datatyper. Bufferoverløb skal således undgås ved at opretholde en høj grad af korrekthed i kode, som udfører buffer ledelse. Det har også længe været anbefalet at undgå standard bibliotekets funktioner, som ikke grænser kontrolleres, såsom og. Morris ormen udnyttede et opkald i fingerd.

Velskrevet og testet abstrakte datatype biblioteker, som centralisere og automatisk udføre buffer ledelse, herunder kontrol af grænser, kan reducere forekomsten og virkningen af ​​buffer overflow. De to vigtigste byggesten datatyper i disse sprog, som bufferoverløb almindeligt forekommende er strenge og arrays; Således kan biblioteker forhindrer bufferoverløb i disse datatyper give langt størstedelen af ​​den nødvendige dækning. Stadig, at fiasko bruge disse sikre biblioteker korrekt kan resultere i bufferoverløb og andre sårbarheder; og naturligt, enhver fejl i selve biblioteket er en potentiel sårbarhed. "Safe" bibliotek implementeringer inkluderer "The Better String Library", VSTR og Erwin. Den OpenBSD operativsystemets C-biblioteket giver strlcpy og strlcat funktioner, men disse er mere begrænset end fuld sikre bibliotekets implementeringer.

I september 2007, Technical Report 24731, udarbejdet af C Standards Committee, blev offentliggjort; Den angiver et sæt af funktioner, som er baseret på standard C bibliotekets streng, og I / O-funktioner, med yderligere buffer-size parametre. Men effektiviteten af ​​disse funktioner med henblik på at reducere bufferoverløb kan diskuteres; det kræver programmør indgriben på en per funktionskald grundlag, der svarer til intervention, der kunne gøre det analoge ældre standard biblioteksfunktioner buffer overflow sikker.

Buffer overflow beskyttelse

Buffer overflow beskyttelse bruges til at opdage de mest almindelige bufferoverløb ved at kontrollere, at stakken ikke er blevet ændret, når en funktion returnerer. Hvis det er blevet ændret, programmet afsluttes med en segmentering fejl. Tre sådanne systemer er libsafe, og StackGuard og ProPolice GCC patches.

Microsofts implementering af Forhindring af datakørsel tilstand udtrykkeligt beskytter markøren til den strukturerede Exception Handler fra at blive overskrevet.

Stærkere stak beskyttelse er mulig ved at opdele stakken i to: en for data og en for funktionen returnerer. Denne opdeling er til stede i Forth sprog, selvom det ikke var en sikkerhed-baseret design beslutning. Uanset hvad, er dette ikke en komplet løsning til buffer overflow, som andre end returadressen følsomme data stadig kan overskrives.

Pointer beskyttelse

Bufferoverløb arbejde ved at manipulere pointere. POINT Guard blev foreslået som en compiler-udvidelse til at forhindre hackere i at være i stand til pålideligt at manipulere pointere og adresser. Den fremgangsmåde fungerer ved at have compileren add kode til automatisk XOR-koder pointers før og efter de anvendes. Fordi angriberen ikke ved, hvad værdi vil blive brugt til at indkode / afkode markøren, kan han ikke forudsige, hvad det vil pege på, hvis han overskriver den med en ny værdi. POINT Guard blev aldrig udgivet, men Microsoft gennemført en lignende tilgang, der begynder i Windows XP SP2 og Windows Server 2003 SP1. Snarere end implementere pointer beskyttelse som en automatisk funktion, Microsoft tilføjede en API rutine, som kan kaldes på skøn programmøren. Dette giver mulighed for bedre ydelse, men placerer byrden på programmør til at vide, hvornår det er nødvendigt.

Fordi XOR er lineær, kan en angriber være i stand til at manipulere et kodet pointer ved at overskrive kun de lavere bytes af en adresse. Dette kan gøre det muligt for et angreb for at lykkes, hvis angriberen er i stand til at forsøge at udnytte flere gange eller er i stand til at fuldføre et angreb ved at forårsage en pointer til punkt til et af flere steder. Microsoft tilføjede en tilfældig rotation til deres kodningsskema til at løse denne svaghed til delvise overskriver.

Eksekverbar beskyttelse plads

Eksekverbare beskyttelse plads er en tilgang til buffer overflow beskyttelse, som forhindrer udførelse af kode på stakken eller bunke. En hacker kan bruge bufferoverløb til at indsætte vilkårlig kode i hukommelsen af ​​et program, men med eksekverbare beskyttelse plads, vil ethvert forsøg på at udføre denne kode forårsage en undtagelse.

Nogle CPU'er understøtter en funktion kaldet NX eller XD bit, hvilket sammenholdt med software, kan bruges til at markere sider af data som læses og skrivbar men ikke eksekverbar.

Nogle Unix operativsystemer skib med eksekverbare beskyttelse plads. Nogle valgfrie pakker inkluderer:

  • PaX
  • Exec Shield
  • Openwall

Nyere varianter af Microsoft Windows understøtter også eksekverbare plads beskyttelse, kaldet Data Execution Prevention. Proprietære tilføjelser kan nævnes:

  • BufferShield
  • StackDefender

Eksekverbar beskyttelse plads generelt ikke beskytter mod tilbagevenden-til-libc-angreb, eller enhver anden angreb, som ikke er afhængig af udførelsen af ​​angriberne koden. , På 64-bit systemer, der anvender ASLR, som beskrevet nedenfor, eksekverbar beskyttelse plads gør det imidlertid langt vanskeligere at gennemføre sådanne angreb.

Adresse plads layout randomisering

Adresseområde layout randomisering er en computer sikkerhedsfunktion, som indebærer at arrangere positionerne af nøgledata områder, som regel herunder bunden af ​​eksekverbare og placering af biblioteker, bunke, og stak, tilfældigt i en proces "adresserum.

Randomisering af den virtuelle hukommelse adresser, hvor funktioner og variable kan findes kan gøre udnyttelsen af ​​en buffer overflow vanskeligere, men ikke umuligt. Det tvinger også angriberen at skræddersy udnyttelsen forsøget på at den enkelte system, som folier forsøg på internet orme. En lignende, men mindre effektiv metode er at variablernes vægtgrundlag, idet processer og biblioteker i det virtuelle adresserum.

Deep packet inspection

Brugen af ​​deep packet inspection kan registrere, på nettet perimeter, at meget grundlæggende fjerntliggende forsøg udnytte bufferoverløb ved brug af angreb signaturer og heuristik. Disse er i stand til at blokere pakker, som har underskrevet af en kendt angreb, eller hvis der registreres en lang række af No-Driftsvejledning blev disse engang bruges, når placeringen af ​​udnytte s nyttelast er lidt variabel.

Packet scanning er ikke en effektiv fremgangsmåde, da den kun kan forhindre kendte angreb, og der er mange måder, en NOP-slæde 'kan kodes. Shellcode bruges af angribere kan gøres alfanumerisk, metamorfe, eller selvstændig modificerende at undgå opdagelse ved heuristiske pakke scannere og intrusion detection systemer.

Historie

Buffer overflow blev forstået og delvist offentligt dokumenteret så tidligt som 1972, da den Computer Security Technology Planlægning Undersøgelse lagt ud teknikken: "Koden udfører denne funktion virker ikke kontrollere kilde og destination adresser korrekt, tillader dele af skærmen til at blive overlejret af brugeren. Dette kan anvendes til at injicere kode i den skærm, vil tillade brugeren at tage kontrol over maskinen. " Dag, vil skærmen blive benævnt kernen.

Den tidligste dokumenterede fjendtlig udnyttelse af en buffer overflow var i 1988. Det var en af ​​flere bedrifter anvendes af Morris ormen at sprede sig over internettet. Programmet udnyttes var en tjeneste på Unix kaldet finger. Senere, i 1995, Thomas Lopatic uafhængigt genopdaget buffer overflow og offentliggjort sine resultater på Bugtraq sikkerhed postliste. Et år senere, i 1996, Elias Levy offentliggjort i Phrack magasin papiret "smadrer Stack for sjov og profit", en trin-for-trin introduktion til at udnytte stack-baseret buffer overflow sårbarheder.

Siden da har mindst to store internet orme udnyttes bufferoverløb at kompromittere en lang række systemer. Udnyttet i 2001, Code Red ormen et bufferoverløb i Microsofts Internet Information Services 5.0 og i 2003 SQL Slammer ormen inficerede maskiner kører Microsoft SQL Server 2000.

I 2003 har bufferoverløb stede i licens Xbox-spil blevet udnyttet til at tillade software uden licens, herunder homebrew spil, til at køre på konsollen uden behov for hardware ændringer, kendt som modchips. PS2 Uafhængighed Exploit også brugt en buffer overflow at opnå det samme til PlayStation 2. Twilight hack opnået det samme med Wii, ved hjælp af en buffer overflow i The Legend of Zelda: Twilight Princess.

  0   0
Forrige artikel XAML
Næste artikel Ashgabat biograf

Kommentarer - 0

Ingen kommentar

Tilføj en kommentar

smile smile smile smile smile smile smile smile
smile smile smile smile smile smile smile smile
smile smile smile smile smile smile smile smile
smile smile smile smile
Tegn tilbage: 3000
captcha