Zabezpečení přístupu do paměti

Zabezpečení přístupu do paměti  je koncept ve vývoji softwaru, jehož cílem je vyhnout se chybám , které vedou k zranitelnostem souvisejícím s přístupem k paměti RAM počítače , jako je přetečení vyrovnávací paměti a visící ukazatele .

Programovací jazyky s nízkou úrovní abstrakce, jako je C a C++ , které podporují přímý přístup k paměti počítače (libovolná aritmetika ukazatelů , alokace paměti a dealokace ) a přetypování , nemají automatickou kontrolu hranic polí bezpečné . z hlediska přístupu do paměti [1] [2] . Jazyky C a C++ však poskytují nástroje (jako jsou chytré ukazatele ) pro zlepšení zabezpečení přístupu do paměti. Techniky správy paměti slouží stejnému účelu [3] . Vyhnout se chybám v přístupu do paměti, zejména ve složitých systémech, však často není možné [4] .

Chyby v přístupu do paměti

Jednou z nejběžnějších tříd softwarových zranitelností jsou problémy se zabezpečením paměti [5] [6] . Tento typ zranitelnosti je znám již více než 30 let [7] . Zabezpečení paměti znamená zabránění pokusům o použití nebo úpravu dat, pokud to programátor při vytváření softwarového produktu záměrně nepovolil [8] .

Mnoho programů kritických pro výkon je implementováno v programovacích jazycích s nízkou úrovní abstrakce ( C a C++ ), které jsou náchylné k tomuto typu zranitelnosti. Nedostatek zabezpečení těchto programovacích jazyků umožňuje útočníkům získat plnou kontrolu nad programem, změnit tok kontroly a mít neoprávněný přístup k důvěrným informacím [9] . V současné době byla navržena různá řešení problémů souvisejících s přístupem do paměti. Ochranné mechanismy musí být účinné jak z hlediska bezpečnosti, tak výkonu [10] .

Chyby paměti byly poprvé zveřejněny v roce 1972 [11] . A pak byly problémem mnoha softwarových produktů, nástroje, který vám umožňuje používat exploity . Například červ Morris používal mnoho zranitelností, z nichž některé souvisely s chybami paměti [12] .

Typy chyb paměti

Existuje několik typů chyb paměti (zranitelnosti), které se mohou vyskytnout v některých programovacích jazycích: [13] [14] [15]

• Array Bound Violation –  určený při definování pole. Samostatně vyniká speciální podtyp -chyba nezapočítané jednotky[16]. Vyskytuje se při absenci kontrol hranic polí ařetězců(C, C++)[17].
  • Přetečení vyrovnávací paměti  - zápis mimo vyrovnávací paměť alokovanou v paměti. Vyvolá se při pokusu zapsat do vyrovnávací paměti blok dat, který je větší než velikost vyrovnávací paměti. V důsledku přetečení může dojít k poškození dat umístěných vedle vyrovnávací paměti [18] nebo program zcela změní své chování až do interpretace zapsaných dat jako spustitelného kódu [19] . Využití této zranitelnosti je jednou z nejpopulárnějších metodhackování počítačových systémů [20] .
  • Reading out of buffer bounds  - čtení mimo buffer alokovaný v paměti. Důsledkem může být porušení zabezpečení systému (ztráta důvěrnosti), nestabilní a nesprávné chování programu, chybypřístupových právechdo paměti[21]. Tato chyba zabezpečení je zahrnuta v seznamu nejběžnějších a nejnebezpečnějších softwarových chyb[22].

• Chyby při práci s dynamickou pamětí  – nesprávná likvidace dynamicky alokované paměti a ukazatelů. V tomto případě se alokace paměti pro objekty provádí během provádění programu [23] , což může vést k chybám za běhu. Tato chyba zabezpečení se týká programovacích jazyků s nízkou úrovní abstrakce, které podporují přímý přístup do paměti počítače (C, C++) [24] .
  • Visící ukazatel [25]  je ukazatel, který neodkazuje na platný objekt odpovídajícího typu. Tento typ ukazatele se vyskytuje, když byl objekt odstraněn (nebo přesunut), ale hodnota ukazatele nebyla změněna nanull. V tomto případě stále ukazuje na paměťové místo, kde daný objekt sídlil. V některých případech to může způsobit, že útočník získá důvěrné informace; nebo, pokud systém již přerozdělil adresovatelnou paměť pro jiný objekt, může přístup visícího ukazatele poškodit data tam umístěná [26] . Konkrétní podtyp chyby, použití po uvolnění (přístup k uvolněné oblasti paměti), je častou příčinou chyb programu [27] , jako jsouwebového prohlížeče [28] .
  • Přístup k nulovému ukazateli . Nulový ukazatel má speciální rezervovanou hodnotu indikující, že daný ukazatel neodkazuje na platný objekt [29] . Nulové ukazatele způsobí výjimku [30] a zhroutí program.
  • Uvolnění dříve nepřidělené paměti  je pokus o uvolnění oblasti RAM, která není aktuálně přidělena (tj. volná). Nejčastěji se to projevuje dvojitým uvolňováním [31] , kdy dochází k opakovanému pokusu o uvolnění již uvolněné paměti. Tato akce může způsobit chybu správce paměti [32] . V C se to stane, když je funkce zdarma volána opakovaněse stejným ukazatelem, bez mezilehlé alokace paměti.
  • Používání různých správců paměti  je chybou, která přeruší spojení alokátor paměti – dealokátor a pro práci s jedním segmentem používá různé nástroje. Například v C++ pomocí free na části paměti alokované s new nebo podobně pomocí delete after malloc . Standard C++ nepopisuje žádný vztah mezi new / delete a funkcemi dynamické paměti C, ačkoli new / delete jsou obecně implementovány jako malloc / free wrapper [33] [34] . Smíšené použití může způsobit nedefinované chování [35] .
  • Ztráta ukazatele  je ztráta adresy alokovaného paměťového fragmentu při jeho přepsání novou hodnotou, která odkazuje na jinou paměťovou oblast [36] . V tomto případě již není přístupná paměť adresovaná předchozím ukazatelem. Tento typ chyby má za následek nevracení paměti , protože přidělenou paměť nelze uvolnit. V C se to může stát, když znovu přiřadíte výsledek malloc ke stejnému ukazateli, aniž byste mezi tím uvolnili paměť.

• Neinicializované proměnné  proměnné, které bylydeklarovány, ale nebyly nastaveny na nějakou hodnotu známou před jejichProměnné budou mít hodnotu, ale obecně je bude obtížné předvídat. Zranitelnosti paměti mohou vzniknout v přítomnostineinicializovaných („divokých“) ukazatelů[37]. Tyto ukazatele jsou svým chováním podobnévisícím ukazatelům, pokus o přístup k nim bude ve většině případů doprovázenchybami přístupunebo poškozením dat. Je však možné získat důvěrné informace, které mohly v této paměťové oblasti zůstat po předchozím použití[38][39].

• Chyby nedostatku paměti  jsou problémy, ke kterým dochází, když pro daný program není dostatek dostupné paměti.
  • Přetečení zásobníku  - program překročí množství informací, které může být vzásobníku volání(ukazatel na vrchol zásobníku přesahuje hranice povolené oblasti). V tomto případě program spadne [40] . Příčinou chyby může být hluboká (nebo nekonečná)rekurzenebo velké množství alokace paměti prolokální proměnnéna zásobníku [41] .
  • haldy pokus  programu alokovat více paměti, než má k dispoziciJe to důsledek častého (Java[42]) a často nesprávného zacházení sdynamickou pamětí. Operační systém v případě chyby ukončí ze svého pohledu pro tento proces nejvhodnější proces (často ten, který chybu způsobil, ale někdy je to libovolné[43]).

Detekce chyb

Případné chyby práce s pamětí lze odhalit jak při kompilaci programu, tak při provádění ( ladění ).

Kromě varování z kompilátoru se k detekci chyb před vytvořením programu používají analyzátory statického kódu . Umožňují vám pokrýt významnou část nebezpečných situací podrobnějším zkoumáním zdrojového kódu než povrchní analýzou kompilátoru. Statické analyzátory mohou detekovat: [44] [45] [46] [47]

• Pole mimo hranice
• Použití visících (nebo nulových či neinicializovaných) ukazatelů
• Nesprávné použití funkcí knihovny
• Úniky paměti kvůli špatnému zacházení s ukazateli

Během ladění programu lze použít speciální správce paměti. V tomto případě se kolem objektů alokovaných v haldě vytvoří „mrtvé“ oblasti paměti, a když se do nich debugger dostane, dokáže detekovat chyby [48] . Alternativou jsou specializované virtuální stroje , které kontrolují přístup k paměti ( Valgrind ). Detekci chyb napomáhají systémy kódové instrumentace , včetně těch, které poskytuje kompilátor (Sanitizer [49] ).

Bezpečnostní metody

Většina jazyků na vysoké úrovni řeší tyto problémy odstraněním aritmetiky ukazatele z jazyka, omezením možnosti přetypování a zavedením garbage collection jako jediného schématu správy paměti [50] . Na rozdíl od nízkoúrovňových jazyků , kde je důležitá rychlost, vysokoúrovňové jazyky většinou provádějí dodatečné kontroly [51] , jako je kontrola hranic při přístupu k polím a objektům [52] .

Aby se zabránilo únikům paměti a prostředků a zajistila se bezpečnost výjimek, moderní C++ používá chytré ukazatele . Obvykle se jedná o třídu, která napodobuje rozhraní běžného ukazatele a přidává další funkce [53] , jako je kontrola hranic polí a objektů, automatické řízení alokace a dealokace paměti pro používaný objekt. Pomáhají implementovat programovací idiom Resource Acquisition is Initialization (RAII), ve kterém je získání objektu neoddělitelně spojeno s jeho inicializací a uvolnění je nerozlučně spojeno s jeho zničením [54] .

Při používání knihovních funkcí byste měli věnovat pozornost jejich návratovým hodnotám , abyste odhalili možná narušení jejich provozu [55] . Funkce pro práci s dynamickou pamětí v C signalizují chybu (nedostatek volné paměti požadované velikosti) vrácením nulového ukazatele místo ukazatele na blok paměti [56] ; C++ používá výjimky [57] . Správné řešení těchto situací umožňuje vyhnout se nesprávnému (abnormálnímu) ukončení programu [58] .

Kontroly hranic při použití ukazatelů zlepšují zabezpečení. Takové kontroly se přidávají v době kompilace a mohou zpomalit programy; pro jejich urychlení byla vyvinuta speciální hardwarová rozšíření (například Intel MPX [59] ) .

Na nižších úrovních abstrakce existují speciální systémy, které zajišťují bezpečnost paměti. Na úrovni operačního systému se jedná o správce virtuální paměti , který odděluje dostupné oblasti paměti pro jednotlivé procesy ( podpora multitaskingu ) a synchronizační prostředky pro podporu multithreadingu [60] . Hardwarová vrstva má také tendenci zahrnovat některé mechanismy, jako jsou ochranné kroužky [61] .

Poznámky

1. ↑ Anketa Erika. Poznámky k přednáškám o jazykové bezpečnosti . - Radboud University Nijmegen, 2016. - 21. ledna. / "Jazykové funkce, které narušují bezpečnost paměti, zahrnují..."
2. ↑ Laszlo Szekeres, Mathias Payer, Dawn Song. SoK: Eternal War in Memory . — 2013 IEEE Symposium on Security and Privacy, 2013. / „Chyby poškození paměti v softwaru napsaném v jazycích nižší úrovně, jako je C nebo C++, jsou jedním z nejstarších problémů v počítačové bezpečnosti.“
3. ↑ Standard ISO C++ Foundation. C++ FAQ:  Správa paměti . isocpp.org . Získáno 10. února 2022. Archivováno z originálu 10. září 2018.
4. ↑ Standard ISO C++ Foundation. C++ FAQ:  Správa paměti . isocpp.org . Získáno 10. února 2022. Archivováno z originálu 10. září 2018. / "Je jasné, že pokud má váš kód všude nové operace, operace mazání a aritmetiku ukazatelů, někde se pokazíte a získáte úniky, zbloudilé ukazatele atd." To platí nezávisle na tom, jak svědomití jste se svými alokacemi: nakonec složitost kódu překoná čas a úsilí, které si můžete dovolit."
5. ↑ Victor van der Veen, Nitish dutt-Sharma, Lorenzo Cavallaro, Herbert Bos. Chyby paměti: Minulost, současnost a budoucnost . — RAID'12; Amsterdam, Nizozemsko, 2012. - 12.-14. září. / "... a stále patří mezi 3 nejnebezpečnější softwarové chyby."
6. ↑ Píseň úsvitu. Bezpečnost paměti – útoky a obrana . - Berkeley CS161 Computer Security, 2015. - Jaro. / "Ve skutečnosti, po chybách konfigurace, jsou chyby implementace pravděpodobně největší jednotlivou třídou chyb zabezpečení využívanou v praxi."
7. ↑ Laszlo Szekeres, Mathias Payer, Dawn Song. SoK: Eternal War in Memory . — 2013 IEEE Symposium on Security and Privacy, 2013. / «Tento problém existuje již více než 30 let…»
8. ↑ Píseň úsvitu. Bezpečnost paměti – útoky a obrana . - Berkeley CS161 Computer Security, 2015. - Jaro. / "... brání útočníkům číst nebo zapisovat do paměťových míst, která nejsou určena programátorem."
9. ↑ Laszlo Szekeres, Mathias Payer, Dawn Song. SoK: Eternal War in Memory . — 2013 IEEE Symposium on Security and Privacy, 2013. / Aplikace napsané v jazycích nižší úrovně, jako je C nebo C++, jsou náchylné k těmto druhům chyb. Nedostatek zabezpečení paměti… umožňuje útočníkům zneužít chyby paměti tím, že zlomyslně změní chování programu nebo dokonce převezmou plnou kontrolu nad tokem kontroly.“
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. Chyby paměti: Minulost, současnost a budoucnost . — RAID'12; Amsterdam, Nizozemsko, 2012. - 12.-14. září. / "Chyby paměti byly poprvé veřejně diskutovány v roce 1972 studijním panelem plánování počítačové bezpečnosti."
12. ↑ Victor van der Veen, Nitish dutt-Sharma, Lorenzo Cavallaro, Herbert Bos. Chyby paměti: Minulost, současnost a budoucnost . — RAID'12; Amsterdam, Nizozemsko, 2012. - 12.-14. září. / "Internetový červ zneužil řadu zranitelností, včetně chyb souvisejících s pamětí."
13. ↑ Laszlo Szekeres, Mathias Payer, Dawn Song. SoK: Eternal War in Memory . — 2013 IEEE Symposium on Security and Privacy, 2013.
14. ↑ Píseň úsvitu. Bezpečnost paměti – útoky a obrana . - Berkeley CS161 Computer Security, 2015. - Jaro.
15. ↑ Katrina Tsipenyuk, Brian Chess, Gary McGraw. Sedm zhoubných království: Taxonomie chyb zabezpečení softwaru . - NIST Workshop o nástrojích, technikách a metrikách zabezpečení softwaru, Long Beach, CA, 2005. - listopad.
16. ↑ Edsger W. Dijkstra. Proč by číslování mělo začínat nulou (EWD 831) . - Plataanstraat 5, 5671 AL NUENEN, Nizozemsko, 1982. - 11. srpna. / "... použití ostatních tří konvencí bylo neustálým zdrojem nemotornosti a chyb..."
17. ↑ Richard Jones a Paul Kelly. Kontrola mezí pro C . - Imperial College, 1995. - Červenec. / "Jednou reakcí na tuto analýzu je vyřazení C, protože tento nedostatek účinné kontroly je zodpovědný za mnoho selhání softwaru."
18. ↑ John Erickson. Hackování. The Art of Exploit . - Petrohrad. : Symbol-Plus, 2010. - S.  139 . — ISBN 978-5-93286-158-5 .
19. ↑ John Erickson. Hackování. The Art of Exploit . - Petrohrad. : Symbol-Plus, 2010. - S.  142 . — ISBN 978-5-93286-158-5 .
20. ↑ David A. Wheeler. Bezpečné programování JAK . — Publikováno v3.72. — 2015. / „Přetečení vyrovnávací paměti je extrémně běžná a nebezpečná bezpečnostní chyba…“
21. ↑ Společný výčet slabostí. CWE-126: Přečtení vyrovnávací paměti (8. prosince 2015). Získáno 24. listopadu 2016. Archivováno z originálu dne 27. září 2016.  (neurčitý) / "K tomu obvykle dochází, když se ukazatel nebo jeho index zvýší na pozici za hranicemi vyrovnávací paměti..."
22. ↑ Steve Christey. 2011 CWE/SANS Top 25 nejnebezpečnějších softwarových chyb . MITRE (13. září 2011). Získáno 24. listopadu 2016. Archivováno z originálu 12. dubna 2018. (neurčitý)
23. ↑ Guy Keren. Správa runtime paměti Unix a C/C++ pro programátory (odkaz není k dispozici) (2001-2002). Získáno 24. listopadu 2016. Archivováno z originálu dne 27. září 2016.  (neurčitý)  / "Běhové prostředí definuje nejen to, jak je paměť alokována a uvolněna ..."
24. ↑ Robert C. Seacord. Bezpečné kódování v C a C++ . — Addison-Wesley, 2013. — S.  162 . - ISBN 978-0-321-82213-0 .
25. ↑ Jonathan Afek, Adi Sarabani. Visící ukazatel. Rozbití ukazatele pro zábavu a zisk . — Watchfire Corporation, 2007.
26. ↑ Počítačové noviny. Odkaz nikam nebo nefunkční ukazatel . Získáno 24. listopadu 2016. Archivováno z originálu 22. června 2018.  (neurčitý) / "... zranitelnosti, které mohou být způsobeny zneužitím ukazatelů a odkazů."
27. ↑ Společný výčet slabostí. CWE-416: Use After Free (8. prosince 2015). Získáno 24. listopadu 2016. Archivováno z originálu 18. července 2019.  (neurčitý) / "Odkazování na paměť po jejím uvolnění může způsobit selhání programu, použití neočekávaných hodnot nebo spuštění kódu."
28. ↑ Juan Caballero, Gustavo Grieco, Mark Marron, Antonio Nappa. Undangle: Včasná detekce visících ukazatelů ve zranitelnostech typu Use-After-Free a Double-Free . — IMDEA Software Institute; Madrid, Španělsko. / "Zranitelnosti bez použití po použití rychle rostou na popularitě, zejména při zneužívání webových prohlížečů."
29. ↑ comp.lang.c. Otázka 5.1 . Získáno 24. listopadu 2016. Archivováno z originálu dne 27. září 2016.  (neurčitý) / "V definici jazyka je uvedeno, že pro každý typ ukazatele existuje speciální hodnota ..."
30. ↑ Oracle. Java Platform, Standard Edition 7 API Specifikace . Získáno 24. listopadu 2016. Archivováno z originálu dne 23. dubna 2018.  (neurčitý) / "Vyvolá se, když se aplikace pokusí použít hodnotu null v případě, kdy je vyžadován objekt."
31. ↑ Společný výčet slabostí. CWE-415: Double Free (8. prosince 2015). Získáno 24. listopadu 2016. Archivováno z originálu dne 27. září 2016.  (neurčitý) / "Když program volá free() dvakrát se stejným argumentem..."
32. ↑ Yan Huang. Přetečení haldy a dvojité útoky zdarma . Získáno 24. listopadu 2016. Archivováno z originálu 17. dubna 2018.  (neurčitý) / "Pokud již bylo dříve voláno free(p), dojde k nedefinovanému chování."
33. ↑ Andrej Alexandrescu. Moderní design C++: aplikované obecné programování a návrhové vzory . - Addison Wesley, 2001.  (nedostupný odkaz) / "... je obvykle implementován jako tenký obal kolem alokátoru haldy C ..."
34. ↑ Guy Keren. Správa runtime paměti Unix a C/C++ pro programátory (odkaz není k dispozici) (2001-2002). Získáno 25. listopadu 2016. Archivováno z originálu dne 27. září 2016.  (neurčitý)  / "Například nový operátor kompilátoru GNU C++ ve skutečnosti vyvolává funkci C runtime malloc()."
35. ↑ Správa paměti . Získáno 25. listopadu 2016. Archivováno z originálu 10. září 2018.  (neurčitý) / "C++ operátory new a delete zaručují správnou konstrukci a zničení... Funkce ve stylu C... to nezaručují."
36. ↑ OWASP. únik paměti . Staženo 25. listopadu 2016. Archivováno z originálu 23. listopadu 2016. (neurčitý)
37. ↑ Problémy související s ukazateli . Datum přístupu: 25. listopadu 2016. Archivováno z originálu 26. února 2013.  (neurčitý) / "Nic není znepokojivější než 'divoké' ukazatele!"
38. ↑ Halvar Flake. Útoky na neinicializované lokální proměnné (2006). Získáno 25. listopadu 2016. Archivováno z originálu 3. června 2016.  (neurčitý) / "Pak se díváme na následující situaci..."
39. ↑ Společný výčet slabostí. CWE-457: Použití neinicializované proměnné (8. prosince 2015). Získáno 25. listopadu 2016. Archivováno z originálu 2. října 2016.  (neurčitý) / "Útočník může někdy ovládat nebo číst tento obsah."
40. ↑ Používání a portování GNU Fortran . James Craig, Burley (1. června 1991). Datum přístupu: 25. listopadu 2016. Archivováno z originálu 5. října 2012. (neurčitý)
41. ↑ Danny Kalev. Pochopení přetečení zásobníku (5. září 2000). Datum přístupu: 25. listopadu 2016. Archivováno z originálu 5. října 2012.  (neurčitý) / "Dvě nejčastější příčiny přetečení zásobníku..."
42. ↑ John Boyland. Umístění papíru: Zpracování chyb „Nedostatek paměti“ . — University of Wisconsin-Milwaukee, USA. Archivováno z originálu 22. března 2016. / "Chyba "nedostatek paměti" může být pro program katastrofální, zejména pro program napsaný v jazyce, jako je Java, který často používá alokaci paměti."
43. ↑ Mulyadi Santosa. Když Linuxu dojde paměť (30. 11. 2006). Získáno 15. listopadu 2016. Archivováno z originálu 14. dubna 2018.  (neurčitý) / "... již nemůžete alokovat více paměti a jádro ukončí úlohu (obvykle právě běžící)."
44. ↑ Anders Moller a Michael I. Schwartzbach. Statická programová analýza . - Katedra informatiky, Aarhus University, 2015. - Květen.
45. ↑ Cppcheck - Nástroj pro statickou analýzu kódu C/C++ . Získáno 25. listopadu 2016. Archivováno z originálu 18. ledna 2016.  (neurčitý) / "Zjistit různé druhy chyb ve vašem kódu..."
46. ↑ Sémantické vzory. Analýza bezpečnosti paměti pomocí CheckPointer . Získáno 25. listopadu 2016. Archivováno z originálu 18. dubna 2018.  (neurčitý) / "Programy s ukazateli mohou způsobit různé chyby v přístupu k paměti..."
47. ↑ PVS-Studio. Statická analýza kódu (25. 3. 2015). Získáno 25. listopadu 2016. Archivováno z originálu 25. ledna 2018. (neurčitý)
48. ↑ Emery D. Berger, Benjamin G. Zorn. DieHard: Pravděpodobnostní bezpečnost paměti pro nebezpečné jazyky . — PLDI'06; Ottawa, Ontario, Kanada, 2006. 11.–14. června.
49. ↑ Konstantin Serebryany, Dmitrij Vyukov. Hledání ras a chyb paměti pomocí kompilátorového vybavení . GNU Tools Cauldron (10. července 2012). Získáno 25. listopadu 2016. Archivováno z originálu 12. března 2016. (neurčitý)
50. ↑ Anketa Erika. Zabezpečení založené na jazyku: „Bezpečné“ programovací jazyky ​​(downlink) . Radboud Universiteit Nijmegen . Získáno 25. listopadu 2016. Archivováno z originálu 5. listopadu 2016.  (neurčitý)  / "Ruční správě paměti se lze vyhnout..."
51. ↑ Dinakar Dhurjati a Vikram Adve. Kontrola zpětně kompatibilních hranic pole pro C s velmi nízkou režií . — Katedra počítačových věd University of Illinois v Urbana-Champaign. / „… nevyřešený problém navzdory dlouhé historii práce na zjišťování narušení hranic polí nebo přetečení vyrovnávací paměti, protože dosud nejlepší existující řešení jsou buď příliš drahá pro použití v nasazeném produkčním kódu…“
52. ↑ Bruce Eckel. Myšlení v Javě. Čtvrté vydání . / „Pole i kontejnery zaručují, že je nemůžete zneužít. Ať už používáte pole nebo kontejner, dostanete RuntimeException, pokud překročíte meze, což znamená chybu programátora."
53. ↑ David Kieras. Použití inteligentních ukazatelů C++11 . - Katedra EECS, University of Michigan, 2016. - Červen. / "Inteligentní ukazatele jsou objekty třídy, které se chovají jako vestavěné ukazatele, ale také spravují objekty, které vytvoříte..."
54. ↑ Microsoft Developer Network. Inteligentní ukazatele (moderní C++) . Získáno 25. listopadu 2016. Archivováno z originálu 5. prosince 2017.  (neurčitý) / "Jsou extrémně důležité pro programovací idiom RAII nebo Resource Acquisition is Initialization..."
55. ↑ Společný výčet slabostí. CWE-252: Nekontrolovaná návratová hodnota (8. prosince 2015). Získáno 25. listopadu 2016. Archivováno z originálu 18. července 2019.  (neurčitý) / "Software nekontroluje návratovou hodnotu z metody nebo funkce, což mu může zabránit v detekci neočekávaných stavů a ​​podmínek."
56. ↑ Microsoft Developer Network. malloc . Získáno 25. listopadu 2016. Archivováno z originálu 5. října 2016.  (neurčitý) / "malloc vrátí netypovaný ukazatel na oblast přidělené paměti nebo NULL, pokud není k dispozici dostatek paměti."
57. ↑ operátor nový, operátor nový[ ] . Získáno 25. listopadu 2016. Archivováno z originálu dne 29. března 2018.  (neurčitý) / "při selhání alokace paměti vyvolá std::bad_alloc nebo jinou výjimku odvozenou z std::bad_alloc (od C++ 11)"
58. ↑ Paul a Harvey Deitelovi. C: jak programovat .
59. ↑ Intel Developer Zone. Úvod do Intel® Memory Protection Extensions (16. července 2013). Získáno 25. listopadu 2016. Archivováno z originálu 5. května 2019. (neurčitý)
60. ↑ Sarah Diesburgová. Ochrana paměti: prostory jádra a uživatelských adres . Získáno 25. listopadu 2016. Archivováno z originálu 9. srpna 2017. (neurčitý)
61. ↑ Michael D. Schroeder a Jerome H. Saltzer. Hardwarová architektura pro implementaci ochranných prstenů . - Třetí symposium ACM o principech operačních systémů, Palo Alto, Kalifornie, 1971. - 18.-20. října.

Literatura

• Eric Anketa. Poznámky k přednáškám o jazykové  bezpečnosti . - Radboud University Nijmegen, 2016. - 21. ledna.
• David A. Wheeler. Bezpečné programování JAK . - Edice v3.72. — 2015.

Odkazy

Obecné publikace

• Laszlo Szekeres, Mathias Payer, Tao Wei, Dawn Song. SoK: Eternal War in Memory  (anglicky) . - IEEE Computer Society Washington, DC, USA, 2013. - 19.-22. května. — ISBN 978-0-7695-4977-4 . - doi : 10.1109/SP.2013.13 .
• Píseň úsvitu. Bezpečnost paměti - Attacks and Defenses  (anglicky) . - Berkeley CS 161 Computer Security, 2015. - Jaro.
• Katrina Tsipenyuk, Brian Chess, Gary McGraw. Sedm zhoubných království: Taxonomie chyb zabezpečení softwaru  . - 2005. - 12. prosince. — ISSN 1540-7993 . - doi : 10.1109/MSP.2005.159 .
• Emery D. Berger, Benjamin G. Zorn. DieHard: Pravděpodobnostní bezpečnost paměti pro nebezpečné  jazyky . — PLDI '06; Ottawa, Ontario, Kanada, 2006. 11.–14. června. — ISBN 1-59593-320-4 . - doi : 10.1145/1133981.1134000 .
• Eric Anketa. Zabezpečení založené na jazyku: „Bezpečné“ programovací jazyky  ​​(anglicky)  (downlink) . Radboud Universiteit Nijmegen . Datum přístupu: 24. listopadu 2016. Archivováno z originálu 5. listopadu 2016.
• Victor van der Veen, Nitish dutt-Sharma, Lorenzo Cavallaro, Herbert Bos. Chyby paměti: Minulost, současnost a  budoucnost . — RAID'12; Amsterdam, Nizozemsko, 2012. - 12.-14. září. - ISBN 978-3-642-33337-8 . - doi : 10.1007/978-3-642-33338-5_5 .

Tematické publikace

• Guy Keren. Správa runtime paměti Unix a C/C++ pro programátory  (anglicky)  (nedostupný odkaz) (2001-2002). Získáno 24. listopadu 2016. Archivováno z originálu dne 27. září 2016.
• Jonathan Afek, Adi Sarabani. Visící ukazatel. Rozbití ukazatele pro zábavu a  zisk . — Watchfire Corporation, 2007.
• Juan Caballero, Gustavo Grieco, Mark Marron, Antonio Nappa. Undangle : Včasná detekce visících ukazatelů ve zranitelnostech bez použití a bez dvojitého použití  . — ISSTA 2012; Minneapolis, MN, USA, 2012. - 15.-20. července. — ISBN 978-1-4503-1454-1 . doi : 10.1145 / 2338965.2336769 .
• Yan Huang. Heap Overflows and Double-Free Attacks  (anglicky) (2016). Datum přístupu: 24. listopadu 2016.
• Halvarské vločky. Útoky na neinicializované lokální  proměnné . Black Hat Federal (2006). Datum přístupu: 24. listopadu 2016.
• John Boyland. Umístění papíru : Zpracování chyb "Nedostatek paměti"  . — Workshop ECOOP 2005 o výjimečném zacházení v objektově orientovaných systémech; University of Wisconsin-Milwaukee, USA, 2005. - červenec. Archivováno z originálu 22. března 2016.
• David Kieras. Použití inteligentních ukazatelů C++11  . - Katedra EECS, University of Michigan, 2016. - Červen.
• Dinakar Dhurjati, Vikram Adv. Kontrola zpětně kompatibilních hranic pole pro C s velmi nízkou  režií . — ICSE '06; Šanghaj, Čína, 2006. 20.–28. května. — ISBN 1-59593-375-1 . - doi : 10.1145/1134285.1134309 .