Hukommelsesadgangssikkerhed

Den aktuelle version af siden er endnu ikke blevet gennemgået af erfarne bidragydere og kan afvige væsentligt fra den version , der blev gennemgået den 28. juni 2021; checks kræver 6 redigeringer .

Hukommelsesadgangssikkerhed  er et koncept inden for softwareudvikling, der har til formål at undgå fejl , der fører til sårbarheder relateret til adgang til en computers RAM , såsom bufferoverløb og dinglende pointer .

Programmeringssprog med et lavt abstraktionsniveau, såsom C og C++ , der understøtter direkte adgang til computerhukommelse (arbitrær pointer -aritmetik , hukommelsesallokering og deallokering ) og typecasting , men som ikke har automatisk array- grænsekontrol sikre med hensyn til hukommelsesadgang [1] [2] . C og C++ giver dog værktøjer (såsom smarte pointere ) til at forbedre sikkerheden for hukommelsesadgang. Hukommelseshåndteringsteknikker tjener samme formål [3] . Men at undgå hukommelsesadgangsfejl, især i komplekse systemer, er ofte ikke muligt [4] .

Hukommelsesadgang sårbarheder

En af de mest almindelige klasser af softwaresårbarheder er hukommelsessikkerhedsproblemer [5] [6] . Denne form for sårbarhed har været kendt i over 30 år [7] . Hukommelsessikkerhed betyder at forhindre forsøg på at bruge eller ændre data, medmindre det med vilje blev tilladt af programmøren, da softwareproduktet blev oprettet [8] .

Mange præstationskritiske programmer er implementeret i programmeringssprog med et lavt abstraktionsniveau ( C og C++ ), som er tilbøjelige til denne type sårbarhed. Manglen på sikkerhed i disse programmeringssprog giver angribere mulighed for at få fuld kontrol over programmet, ændre kontrolstrømmen og have uautoriseret adgang til fortrolig information [9] . I øjeblikket er forskellige løsninger på problemer relateret til hukommelsesadgang blevet foreslået. Beskyttelsesmekanismer skal være effektive både med hensyn til sikkerhed og ydeevne [10] .

Hukommelsesfejl blev først offentliggjort i 1972 [11] . Og så var de problemet med mange softwareprodukter, et værktøj, der giver dig mulighed for at bruge exploits . For eksempel brugte Morris-ormen mange sårbarheder, hvoraf nogle var relateret til hukommelsesfejl [12] .

Typer af hukommelsesfejl

Der er flere typer hukommelsesfejl (sårbarheder), der kan forekomme i nogle programmeringssprog: [13] [14] [15]

• Array Bound Violation -  det område, der er angivet, da arrayet blev defineret. Separat skiller en speciel undertype sig ud -fejlen i en urapporteret enhed[16]. Opstår i fravær af array- ogstrenggrænsekontrol(C, C++)[17].
  • Bufferoverløb  - skriv uden for den buffer, der er allokeret i hukommelsen. Opstår, når der gøres et forsøg på at skrive til en buffer en blok af data, der er større end størrelsen af ​​bufferen. Som et resultat af et overløb kan data placeret ved siden af ​​bufferen [18] blive beskadiget , eller programmet vil fuldstændig ændre sin adfærd, op til fortolkning af de skrevne data som eksekverbar kode [19] . Udnyttelse af denne sårbarhed er en af ​​de mest populære metodertil at hacke computersystemer [20] .
  • Læsning uden for buffergrænser  - læsning uden for den buffer, der er allokeret i hukommelsen. Konsekvenserne kan være brud på systemsikkerheden (tab af fortrolighed), ustabil og forkert opførsel af programmet, fejli hukommelsesadgangsrettigheder[21]. Denne sårbarhed er inkluderet på listen over de mest almindelige og farlige softwarefejl[22].

• Fejl ved arbejde med dynamisk hukommelse  - forkert bortskaffelse af dynamisk allokeret hukommelse og pointere. I dette tilfælde udføres allokeringen af ​​hukommelse til objekter under udførelsen af ​​programmet [23] , hvilket kan føre til runtime fejl. Denne sårbarhed påvirker programmeringssprog med et lavt abstraktionsniveau, der understøtter direkte adgang til computerhukommelse (C, C++) [24] .
  • En dinglende pointer [25]  er en pointer, der ikke henviser til et gyldigt objekt af den tilsvarende type. Denne type markør opstår, når et objekt er blevet slettet (eller flyttet), men markørens værdi ikke er blevet ændret tilnull. I dette tilfælde peger det stadig på hukommelsesstedet, hvor det givne objekt befandt sig. I nogle tilfælde kan dette få en hacker til at få fortrolige oplysninger; eller, hvis systemet allerede har omallokeret den adresserbare hukommelse til et andet objekt, kan en dinglende pointer-adgang ødelægge de data, der findes der [26] . En specifik undertype af fejl, brug efter fri (adgang til et frigjort hukommelsesområde), er en almindelig årsag til programfejl [27] , såsomwebbrowsersårbarheder [28] .
  • Nul pointer adgang . En null-pointer har en speciel reserveret værdi, der indikerer, at den givne pointer ikke refererer til et gyldigt objekt [29] . En null-pointer vil forårsage en undtagelse [30] og crashe programmet.
  • Frigivelse af tidligere ikke-allokeret hukommelse  er et forsøg på at frigøre et område med RAM, der ikke er allokeret i øjeblikket (det vil sige gratis). Oftest viser dette sig i dobbeltfrigørelse [31] , når der er et gentaget forsøg på at frigøre hukommelse, der allerede er frigivet. Denne handling kan forårsage en hukommelseshåndteringsfejl [ 32] . I C sker dette, når den frie funktion kaldes gentagne gangemed den samme pointer, uden mellemliggende hukommelsesallokering.
  • Brug af forskellige hukommelsesadministratorer  er en fejl, der bryder forbindelsen mellem hukommelsesallokator og deallokator og bruger forskellige værktøjer til at arbejde med ét segment. For eksempel i C++ ved at bruge gratis på et stykke hukommelse, der er allokeret med ny eller på lignende måde ved at bruge delete efter malloc . C++-standarden beskriver ikke noget forhold mellem new / delete og C dynamiske hukommelsesfunktioner, selvom new / delete generelt implementeres som malloc / free wrappers [33] [34] . Blandet brug kan forårsage udefineret adfærd [35] .
  • Tab af en pointer  er tabet af adressen på et tildelt hukommelsesfragment, når det overskrives med en ny værdi, der refererer til et andet hukommelsesområde [36] . I dette tilfælde er hukommelsen adresseret af den forrige markør ikke længere tilgængelig. Denne type fejl resulterer i hukommelseslækager, fordi den allokerede hukommelse ikke kan frigøres. I C kan dette ske, når du gentildeler resultatet af malloc til den samme pointer, uden at frigøre hukommelsen imellem.

• Ikke-initialiserede variabler  variabler, der er bleveterklæret,men ikke sat til en eller anden værdi, der er kendt før det tidspunkt, deVariabler vil have en værdi, men generelt svære at forudsige. Hukommelsessårbarheder kan opstå ved tilstedeværelse afuinitialiserede ("vilde") pointere[37]. Disse pointere ligner i deres adfærddinglende pointere, et forsøg på at få adgang til dem vil i de fleste tilfælde være ledsaget afadgangsfejleller datakorruption. Det er dog muligt at indhente fortrolige oplysninger, der kan være forblevet i dette hukommelsesområde efter en tidligere brug[38][39].

• Fejl uden hukommelse  er problemer, der opstår, når der ikke er nok ledig hukommelse til et givet program.
  • Stack overflow  - programmet overskrider mængden af ​​information, der kan være iopkaldsstakken(markøren til toppen af ​​stakken går ud over grænserne for det tilladte område). I dette tilfælde går programmet ned [40] . Årsagen til fejlen kan være dyb (eller uendelig)rekursioneller en stor mængde hukommelsesallokering forlokale variablerpå stakken [41] .
  • heap-overløb  et program på at allokere mere hukommelse, end der er tilgængelig for det. Det er en konsekvens af den hyppige (Java[42]) og ofte ukorrekte håndtering afdynamisk hukommelse. I tilfælde af en fejl vil operativsystemet afslutte den proces, der er bedst egnet fra sit synspunkt til denne proces (ofte den, der forårsagede fejlen, men nogle gange er den vilkårlig[43]).

Fejlregistrering

Mulige fejl ved at arbejde med hukommelse kan detekteres både under kompilering af programmet og under udførelse ( debugging ).

Ud over advarsler fra compileren bruges statiske kodeanalysatorer til at opdage fejl, før programmet bygges . De giver dig mulighed for at dække en betydelig del af farlige situationer ved at undersøge kildekoden mere detaljeret end en overfladisk analyse af compileren. Statiske analysatorer kan detektere: [44] [45] [46] [47]

• Array uden for grænserne
• Brug af dinglende (eller nul eller ikke-initialiserede) pointere
• Forkert brug af biblioteksfunktioner
• Hukommelseslækager på grund af forkert håndtering af pointere

Under programfejlfinding kan specielle hukommelsesadministratorer bruges. I dette tilfælde oprettes "døde" hukommelsesområder omkring de objekter, der er allokeret i heapen, og når debuggeren kommer ind i dem, kan den opdage fejl [48] . Et alternativ er specialiserede virtuelle maskiner , der kontrollerer hukommelsesadgang ( Valgrind ). Fejldetektering er hjulpet af kodeinstrumenteringssystemer , inklusive dem, der leveres af compileren (Sanitizer [49] ).

Sikkerhedsmetoder

De fleste sprog på højt niveau løser disse problemer ved at fjerne pointaritmetik fra sproget, begrænse muligheden for at caste og introducere affaldsopsamling som det eneste hukommelseshåndteringsskema [50] . I modsætning til sprog på lavt niveau , hvor hastighed er vigtig, udfører sprog på højt niveau for det meste yderligere kontrol [51] , såsom grænsekontrol ved adgang til arrays og objekter [52] .

For at undgå hukommelses- og ressourcelækager og sikre undtagelsessikkerhed bruger moderne C++ smarte pointere . Normalt er de en klasse, der efterligner grænsefladen for en almindelig pointer og tilføjer yderligere funktionalitet [53] , såsom kontrol af grænserne for arrays og objekter, automatisk styring af allokering og deallokering af hukommelse for det objekt, der bruges. De hjælper med at implementere Resource Acquisition is Initialization (RAII) programmeringssproget, hvor erhvervelsen af ​​et objekt er uløseligt forbundet med dets initialisering, og udgivelsen er uløseligt forbundet med dets ødelæggelse [54] .

Når du bruger biblioteksfunktioner, skal du være opmærksom på deres returværdier for at opdage mulige overtrædelser i deres drift [55] . Funktioner til at arbejde med dynamisk hukommelse i C signalerer en fejl (manglende ledig hukommelse af den ønskede størrelse) ved at returnere en nul-pointer i stedet for en pointer til en hukommelsesblok [56] ; C++ bruger undtagelser [57] . Korrekt håndtering af disse situationer giver dig mulighed for at undgå forkert (unormal) afslutning af programmet [58] .

Grænsekontrol ved brug af pointere forbedrer sikkerheden. Sådanne kontroller tilføjes på kompileringstidspunktet og kan bremse programmerne; specielle hardwareudvidelser (for eksempel Intel MPX [59] ) er blevet udviklet for at fremskynde dem .

På de lavere abstraktionsniveauer er der specielle systemer, der giver hukommelsessikkerhed. På operativsystemniveau er dette en virtuel hukommelsesmanager, der adskiller tilgængelige hukommelsesområder for individuelle processer ( multitasking -understøttelse ) og synkroniseringsfaciliteter til at understøtte multithreading [60] . Hardwarelaget har også en tendens til at omfatte nogle mekanismer såsom beskyttelsesringe [61] .

Noter

1. ↑ Erik Poll. Forelæsningsnotater om sprogbaseret sikkerhed . - Radboud Universitet Nijmegen, 2016. - 21. januar. / "Sprogfunktioner, der bryder hukommelsessikkerheden omfatter..."
2. ↑ Laszlo Szekeres, Mathias Payer, Dawn Song. SoK: Eternal War in Memory . — 2013 IEEE Symposium on Security and Privacy, 2013. / "Hukommelseskorruptionsfejl i software skrevet på lavniveausprog som C eller C++ er et af de ældste problemer inden for computersikkerhed."
3. ↑ ISO Standard C++ Foundation. C++ FAQ:  Hukommelseshåndtering . isocpp.org . Hentet 10. februar 2022. Arkiveret fra originalen 10. september 2018.
4. ↑ ISO Standard C++ Foundation. C++ FAQ:  Hukommelseshåndtering . isocpp.org . Hentet 10. februar 2022. Arkiveret fra originalen 10. september 2018. / "Det er klart, at hvis din kode har nye operationer, sletteoperationer og pointer-aritmetik overalt, kommer du til at rode et sted og få utætheder, vildfarne pointere osv." Dette er sandt uafhængigt af, hvor samvittighedsfuld du er med dine tildelinger: til sidst vil kompleksiteten af ​​koden overvinde den tid og indsats, du har råd til."
5. ↑ Victor van der Veen, Nitish dutt-Sharma, Lorenzo Cavallaro, Herbert Bos. Hukommelsesfejl: fortiden, nutiden og fremtiden . — RAID'12; Amsterdam, Holland, 2012. - 12.-14. september. / "... og er stadig blandt de 3 mest farlige softwarefejl."
6. ↑ Dawn Song. Hukommelsessikkerhed - Angreb og forsvar . - Berkeley CS161 Computer Security, 2015. - Forår. / "Faktisk er implementeringsfejl efter konfigurationsfejl sandsynligvis den største enkeltklasse af sikkerhedsfejl, der udnyttes i praksis."
7. ↑ Laszlo Szekeres, Mathias Payer, Dawn Song. SoK: Eternal War in Memory . — 2013 IEEE Symposium on Security and Privacy, 2013. / «Dette problem har eksisteret i mere end 30 år …»
8. ↑ Dawn Song. Hukommelsessikkerhed - Angreb og forsvar . - Berkeley CS161 Computer Security, 2015. - Forår. / "... forhindrer angribere i at læse eller skrive til andre hukommelsesplaceringer end dem, programmøren har tiltænkt."
9. ↑ Laszlo Szekeres, Mathias Payer, Dawn Song. SoK: Eternal War in Memory . — 2013 IEEE Symposium on Security and Privacy, 2013. / Ansøgninger skrevet på lavniveausprog som C eller C++ er tilbøjelige til denne slags fejl. Manglen på hukommelsessikkerhed ... gør det muligt for angribere at udnytte hukommelsesfejl ved ondsindet at ændre programmets adfærd eller endda tage fuld kontrol over kontrol-flowet."
10. ↑ Laszlo Szekeres, Mathias Payer, Dawn Song. SoK: Eternal War in Memory . — 2013 IEEE Symposium on Security and Privacy, 2013 .
11. ↑ Victor van der Veen, Nitish dutt-Sharma, Lorenzo Cavallaro, Herbert Bos. Hukommelsesfejl: fortiden, nutiden og fremtiden . — RAID'12; Amsterdam, Holland, 2012. - 12.-14. september. / "Hukommelsesfejl blev først diskuteret offentligt i 1972 af Computer Security Technology Planning Study Panel."
12. ↑ Victor van der Veen, Nitish dutt-Sharma, Lorenzo Cavallaro, Herbert Bos. Hukommelsesfejl: fortiden, nutiden og fremtiden . — RAID'12; Amsterdam, Holland, 2012. - 12.-14. september. / "Internet-ormen udnyttede en række sårbarheder, inklusive hukommelsesfejl-relaterede."
13. ↑ Laszlo Szekeres, Mathias Payer, Dawn Song. SoK: Eternal War in Memory . — 2013 IEEE Symposium on Security and Privacy, 2013.
14. ↑ Dawn Song. Hukommelsessikkerhed - Angreb og forsvar . - Berkeley CS161 Computer Security, 2015. - Forår.
15. ↑ Katrina Tsipenyuk, Brian Chess, Gary McGraw. Seven Pernicious Kingdoms: A Taxonomy of Software Security Errors . - NIST Workshop om Software Security Assurance Tools, Techniques and Metrics, Long Beach, CA, 2005. - November.
16. ↑ Edsger W. Dijkstra. Hvorfor nummerering skal starte ved nul (EWD 831) . - Plataanstraat 5, 5671 AL NUENEN, Holland, 1982. - 11. august. / "... brugen af ​​de tre andre konventioner har været en konstant kilde til klodsethed og fejltagelser ..."
17. ↑ Richard Jones og Paul Kelly. Grænsekontrol for C . - Imperial College, 1995. - Juli. / "Et svar på denne analyse er at kassere C, da denne mangel på effektiv kontrol er ansvarlig for mange softwarefejl."
18. ↑ John Erickson. Hacking. Udnyttelsens kunst . - Sankt Petersborg. : Symbol-Plus, 2010. - S.  139 . — ISBN 978-5-93286-158-5 .
19. ↑ John Erickson. Hacking. Udnyttelsens kunst . - Sankt Petersborg. : Symbol-Plus, 2010. - S.  142 . — ISBN 978-5-93286-158-5 .
20. ↑ David A. Wheeler. Sikker programmering HOWTO . — Udgivet v3.72. — 2015. / "Bufferoverløb er en ekstremt almindelig og farlig sikkerhedsbrist..."
21. ↑ Opregning af almindelig svaghed. CWE-126: Buffer Over-read (8. december 2015). Hentet 24. november 2016. Arkiveret fra originalen 27. september 2016.  (ubestemt) / "Dette sker typisk, når markøren eller dens indeks inkrementeres til en position uden for bufferens grænser..."
22. ↑ Steve Christey. 2011 CWE/SANS Top 25 mest farlige softwarefejl . MITER (13. september 2011). Hentet 24. november 2016. Arkiveret fra originalen 12. april 2018. (ubestemt)
23. ↑ Guy Keren. Unix og C/C++ Runtime Memory Management for programmører (link utilgængeligt) (2001-2002). Hentet 24. november 2016. Arkiveret fra originalen 27. september 2016.  (ubestemt)  / "Runtime-miljøet definerer ikke kun, hvordan hukommelsen allokeres og frigøres ..."
24. ↑ Robert C. Seacord. Sikker kodning i C og C++ . — Addison-Wesley, 2013. — S.  162 . - ISBN 978-0-321-82213-0 .
25. ↑ Jonathan Afek, Adi Sharabani. Dingler. Smashing the Pointer for sjov og fortjeneste . — Watchfire Corporation, 2007.
26. ↑ Computeravis. Et link til ingen steder eller en brudt pointer . Hentet 24. november 2016. Arkiveret fra originalen 22. juni 2018.  (ubestemt) / "... sårbarheder, der kan være forårsaget af misbrug af pointer og referencer."
27. ↑ Opregning af almindelig svaghed. CWE-416: Brug efter gratis (8. december 2015). Hentet 24. november 2016. Arkiveret fra originalen 18. juli 2019.  (ubestemt) / "Hvis du henviser til hukommelse, efter at den er blevet frigivet, kan det få et program til at gå ned, bruge uventede værdier eller udføre kode."
28. ↑ Juan Caballero, Gustavo Grieco, Mark Marron, Antonio Nappa. Undangle: Tidlig opdagelse af dinglende pointere i Use-After-Free og Double-Free sårbarheder . — IMDEA Software Institute; Madrid, Spanien. / "Use-after-free sårbarheder vokser hurtigt i popularitet, især for at udnytte webbrowsere."
29. ↑ comp.lang.c. Spørgsmål 5.1 . Hentet 24. november 2016. Arkiveret fra originalen 27. september 2016.  (ubestemt) / "Sprogdefinitionen angiver, at for hver pointertype er der en speciel værdi ..."
30. ↑ Oracle. Java Platform, Standard Edition 7 API-specifikation . Hentet 24. november 2016. Arkiveret fra originalen 23. april 2018.  (ubestemt) / "Kastet, når et program forsøger at bruge null i et tilfælde, hvor et objekt er påkrævet."
31. ↑ Opregning af almindelig svaghed. CWE-415: Dobbelt gratis (8. december 2015). Hentet 24. november 2016. Arkiveret fra originalen 27. september 2016.  (ubestemt) / "Når et program kalder free() to gange med det samme argument..."
32. ↑ Yan Huang. Heap-overløb og dobbeltfrie angreb . Hentet 24. november 2016. Arkiveret fra originalen 17. april 2018.  (ubestemt) / "Hvis free(p) allerede er blevet kaldt før, opstår der udefineret adfærd."
33. ↑ Andrei Alexandrescu. Moderne C++ Design: Generisk programmering og anvendte designmønstre . - Addison Wesley, 2001.  (utilgængeligt link) / "... det er normalt implementeret som en tynd indpakning omkring C heap allocator ..."
34. ↑ Guy Keren. Unix og C/C++ Runtime Memory Management for programmører (link utilgængeligt) (2001-2002). Hentet 25. november 2016. Arkiveret fra originalen 27. september 2016.  (ubestemt)  / "For eksempel påkalder GNU C++ compilerens nye operatør funktionen C runtime malloc()."
35. ↑ Hukommelsesstyring . Hentet 25. november 2016. Arkiveret fra originalen 10. september 2018.  (ubestemt) / "C++ operatørerne nye og slette garanterer korrekt konstruktion og ødelæggelse ... C-stil funktionerne ... sikrer ikke det."
36. ↑ OWASP. hukommelseslækage . Hentet 25. november 2016. Arkiveret fra originalen 23. november 2016. (ubestemt)
37. ↑ Problemer relateret til pointere . Dato for adgang: 25. november 2016. Arkiveret fra originalen 26. februar 2013.  (ubestemt) / "Intet er mere forstyrrende end 'vilde' pointer!"
38. ↑ Halvar Flake. Angreb på ikke-initialiserede lokale variabler (2006). Hentet 25. november 2016. Arkiveret fra originalen 3. juni 2016.  (ubestemt) / "Så kigger vi på følgende situation..."
39. ↑ Opregning af almindelig svaghed. CWE-457: Brug af ikke-initialiseret variabel (8. december 2015). Hentet 25. november 2016. Arkiveret fra originalen 2. oktober 2016.  (ubestemt) / "En angriber kan nogle gange kontrollere eller læse dette indhold."
40. ↑ Brug og portering af GNU Fortran . James Craig, Burley (1. juni 1991). Dato for adgang: 25. november 2016. Arkiveret fra originalen 5. oktober 2012. (ubestemt)
41. ↑ Danny Kalev. Forstå Stack Overflow (5. september 2000). Dato for adgang: 25. november 2016. Arkiveret fra originalen 5. oktober 2012.  (ubestemt) / "De to mest almindelige årsager til et stakoverløb..."
42. ↑ John Boyland. Positionspapir: Håndtering af hukommelsesfejl . — University of Wisconsin-Milwaukee, USA. Arkiveret fra originalen den 22. marts 2016. / "En "ikke mere hukommelse"-fejl kan være katastrofal for et program, især et der er skrevet på et sprog som Java, der ofte bruger hukommelsestildeling."
43. ↑ Mulyadi Santosa. Når Linux løber tør for hukommelse (30/11/2006). Hentet 15. november 2016. Arkiveret fra originalen 14. april 2018.  (ubestemt) / "... du kan ikke længere allokere mere hukommelse, og kernen dræber en opgave (normalt den aktuelle, der kører)."
44. ↑ Anders Møller og Michael I. Schwartzbach. Statisk programanalyse . - Datalogisk Institut, Aarhus Universitet, 2015. - Maj.
45. ↑ Cppcheck - Et værktøj til statisk C/C++ kodeanalyse . Hentet 25. november 2016. Arkiveret fra originalen 18. januar 2016.  (ubestemt) / "Opdag forskellige slags fejl i din kode..."
46. ↑ Semantiske designs. Hukommelsessikkerhedsanalyse med CheckPointer . Hentet 25. november 2016. Arkiveret fra originalen 18. april 2018.  (ubestemt) / "Programmer med pointere kan begå en række fejl i forbindelse med adgang til hukommelse..."
47. ↑ PVS-Studio. Statisk kodeanalyse (25/03/2015). Hentet 25. november 2016. Arkiveret fra originalen 25. januar 2018. (ubestemt)
48. ↑ Emery D. Berger, Benjamin G. Zorn. DieHard: Probabilistisk hukommelsessikkerhed for usikre sprog . — PLDI'06; Ottawa, Ontario, Canada, 2006. 11.-14. juni.
49. ↑ Konstantin Serebryany, Dmitry Vyukov. Find løb og hukommelsesfejl med compilerinstrumentering . GNU Tools Cauldron (10. juli 2012). Hentet 25. november 2016. Arkiveret fra originalen 12. marts 2016. (ubestemt)
50. ↑ Erik Poll. Sprogbaseret sikkerhed: 'Sikker' programmeringssprog (downlink) . Radboud Universiteit Nijmegen . Hentet 25. november 2016. Arkiveret fra originalen 5. november 2016.  (ubestemt)  / "Manuel hukommelseshåndtering kan undgås ved at..."
51. ↑ Dinakar Dhurjati og Vikram Adve. Bagudkompatible array-grænser Kontrollerer for C med meget lav overhead . — Department of Computer Science University of Illinois i Urbana-Champaign. / "... et uløst problem på trods af en lang historie med arbejde med at opdage array-grænseoverskridelser eller bufferoverskridelser, fordi de bedste eksisterende løsninger til dato enten er alt for dyre til brug i implementeret produktionskode..."
52. ↑ Bruce Eckel. Tænker i Java. Fjerde Udgave . / "Både arrays og containere garanterer, at du ikke kan misbruge dem. Uanset om du bruger et array eller en container, får du en RuntimeException, hvis du overskrider grænserne, hvilket indikerer en programmørfejl."
53. ↑ David Kieras. Brug af C++11's Smart Pointers . - EECS Department, University of Michigan, 2016. - Juni. / "Smart pointers er klasseobjekter, der opfører sig som indbyggede pointere, men som også administrerer objekter, som du opretter ..."
54. ↑ Microsoft Developer Network. Smart Pointers (Moderne C++) . Hentet 25. november 2016. Arkiveret fra originalen 5. december 2017.  (ubestemt) / "De er ekstremt vigtige for RAII-programmeringssproget eller Resource Acquisition Is Initialization..."
55. ↑ Opregning af almindelig svaghed. CWE-252: Ukontrolleret returværdi (8. december 2015). Hentet 25. november 2016. Arkiveret fra originalen 18. juli 2019.  (ubestemt) / "Softwaren kontrollerer ikke returværdien fra en metode eller funktion, hvilket kan forhindre den i at opdage uventede tilstande og forhold."
56. ↑ Microsoft Developer Network. malloc . Hentet 25. november 2016. Arkiveret fra originalen 5. oktober 2016.  (ubestemt) / "malloc returnerer en utyperet pointer til det tildelte hukommelsesområde eller NULL, hvis der ikke er nok hukommelse tilgængelig."
57. ↑ operatør ny, operatør ny[ ] . Hentet 25. november 2016. Arkiveret fra originalen 29. marts 2018.  (ubestemt) / "kaster std::bad_alloc eller en anden undtagelse afledt af std::bad_alloc (siden C++11) ved manglende tildeling af hukommelse"
58. ↑ Paul og Harvey Deitel. C: hvordan programmeres .
59. ↑ Intel Developer Zone. Introduktion til Intel® Memory Protection Extensions (16. juli 2013). Hentet 25. november 2016. Arkiveret fra originalen 5. maj 2019. (ubestemt)
60. ↑ Sarah Diesburg. Hukommelsesbeskyttelse: Kernel og brugeradresserum . Hentet 25. november 2016. Arkiveret fra originalen 9. august 2017. (ubestemt)
61. ↑ Michael D. Schroeder og Jerome H. Saltzer. En hardwarearkitektur til implementering af beskyttelsesringe . - Tredje ACM-symposium om Operating Systems Principles, Palo Alto, Californien, 1971. - 18.-20. oktober.

Litteratur

• Erik Poll. Forelæsningsnotater om sprogbaseret  sikkerhed . - Radboud Universitet Nijmegen, 2016. - 21. januar.
• David A. Wheeler. Sikker programmering HOWTO . - v3.72 udgave. – 2015.

Links

Generelle publikationer

• Laszlo Szekeres, Mathias Payer, Tao Wei, Dawn Song. SoK: Eternal War in Memory  (engelsk) . - IEEE Computer Society Washington, DC, USA, 2013. - 19.-22. maj. — ISBN 978-0-7695-4977-4 . - doi : 10.1109/SP.2013.13 .
• Dawn sang. Hukommelsessikkerhed - Angreb og forsvar  (engelsk) . - Berkeley CS 161 Computer Security, 2015. - Forår.
• Katrina Tsipenyuk, Brian Chess, Gary McGraw. Seven Pernicious Kingdoms: A Taxonomy of Software Security  Errors . - 2005. - 12. december. — ISSN 1540-7993 . - doi : 10.1109/MSP.2005.159 .
• Emery D. Berger, Benjamin G. Zorn. DieHard: Probabilistisk hukommelsessikkerhed for usikre  sprog . — PLDI '06; Ottawa, Ontario, Canada, 2006. 11.-14. juni. — ISBN 1-59593-320-4 . - doi : 10.1145/1133981.1134000 .
• Erik Poll. Sprogbaseret sikkerhed: 'Sikker' programmeringssprog  (eng.)  (downlink) . Radboud Universiteit Nijmegen . Dato for adgang: 24. november 2016. Arkiveret fra originalen 5. november 2016.
• Victor van der Veen, Nitish dutt-Sharma, Lorenzo Cavallaro, Herbert Bos. Hukommelsesfejl: fortiden, nutiden og  fremtiden . — RAID'12; Amsterdam, Holland, 2012. - 12.-14. september. - ISBN 978-3-642-33337-8 . - doi : 10.1007/978-3-642-33338-5_5 .

Tematiske publikationer

• Guy Keren. Unix og C/C++ Runtime Memory Management for programmører  (engelsk)  (utilgængeligt link) (2001-2002). Hentet 24. november 2016. Arkiveret fra originalen 27. september 2016.
• Jonathan Afek, Adi Sharabani. Dingler. Smashing the Pointer for sjov og  fortjeneste . — Watchfire Corporation, 2007.
• Juan Caballero, Gustavo Grieco, Mark Marron, Antonio Nappa. Undangle : Tidlig opdagelse af dinglende pointere i Use-After-Free og Double-Free sårbarheder  . — ISSTA 2012; Minneapolis, MN, USA, 2012. - 15.-20. juli. — ISBN 978-1-4503-1454-1 . doi : 10.1145 / 2338965.2336769 .
• Yan Huang. Heap-overløb og dobbeltfrie angreb  (engelsk) (2016). Dato for adgang: 24. november 2016.
• Halvar Flake. Angreb på ikke-initialiserede lokale  variabler . Black Hat Federal (2006). Dato for adgang: 24. november 2016.
• John Boyland. Positionspapir : Håndtering af "Men hukommelse"-fejl  . — ECOOP 2005 Workshop om exceptionel håndtering i objektorienterede systemer; University of Wisconsin-Milwaukee, USA, 2005. - Juli. Arkiveret fra originalen den 22. marts 2016.
• David Kieras. Brug af C++11 's Smart Pointers  . - EECS Department, University of Michigan, 2016. - Juni.
• Dinakar Dhurjati, Vikram Adv. Bagudkompatible array-grænser Kontrollerer for C med meget lav  overhead . — ICSE '06; Shanghai, Kina, 2006. 20.-28. maj. — ISBN 1-59593-375-1 . - doi : 10.1145/1134285.1134309 .