Securitate acces la memorie

Securitatea accesului la memorie  este un concept în dezvoltarea de software care urmărește evitarea erorilor care duc la vulnerabilități legate de accesarea memoriei RAM a unui computer , cum ar fi depășirile de buffer și pointerii suspendați .

Limbajele de programare cu un nivel scăzut de abstractizare, cum ar fi C și C++ , care acceptă acces direct la memoria computerului (aritmetică arbitrară pointerului , alocare și dealocare a memoriei ) și tip casting , dar nu au verificare automată a limitelor matricei sigure . în ceea ce privește accesul la memorie [1] [2] . C și C++, totuși, oferă instrumente (cum ar fi indicatori inteligente ) pentru a îmbunătăți securitatea accesului la memorie. Tehnicile de gestionare a memoriei servesc aceluiași scop [3] . Cu toate acestea, evitarea erorilor de acces la memorie, în special în sistemele complexe, nu este adesea posibilă [4] .

Vulnerabilitati de acces la memorie

Una dintre cele mai comune clase de vulnerabilități software sunt problemele de securitate a memoriei [5] [6] . Acest tip de vulnerabilitate este cunoscut de peste 30 de ani [7] . Securitatea memoriei înseamnă prevenirea încercărilor de utilizare sau modificare a datelor cu excepția cazului în care aceasta a fost permisă în mod intenționat de către programator la crearea produsului software [8] .

Multe programe critice pentru performanță sunt implementate în limbaje de programare cu un nivel scăzut de abstractizare ( C și C++ ), care sunt predispuse la acest tip de vulnerabilitate. Lipsa de securitate a acestor limbaje de programare permite atacatorilor să obțină controlul deplin asupra programului, să schimbe fluxul de control și să aibă acces neautorizat la informații confidențiale [9] . În acest moment, au fost propuse diverse soluții la problemele legate de accesul la memorie. Mecanismele de protecție trebuie să fie eficiente atât din punct de vedere al securității, cât și al performanței [10] .

Erorile de memorie au fost făcute publice pentru prima dată în 1972 [11] . Și apoi au fost problema multor produse software, un instrument care vă permite să utilizați exploit -uri . De exemplu, viermele Morris a folosit multe vulnerabilități, dintre care unele erau legate de erori de memorie [12] .

Tipuri de erori de memorie

Există mai multe tipuri de erori de memorie (vulnerabilități) care pot apărea în unele limbaje de programare: [13] [14] [15]

• Încălcarea limitelor matricei -  când a fost definită matricea. Separat, iese în evidență un subtip special -eroarea unei unități nesocotite[16]. Apare în absența verificărilor matricei și așirurilor(C, C++)[17].
  • Buffer overflow  - scrieți în afara bufferului alocat în memorie. Apare atunci când se încearcă să scrie într-un tampon un bloc de date care este mai mare decât dimensiunea tamponului. Ca urmare a unui overflow, datele situate lângă buffer-ul [18] pot fi corupte , sau programul își va schimba complet comportamentul, până la interpretarea datelor scrise ca cod executabil [19] . Exploatarea acestei vulnerabilități este una dintre cele mai populare metodede hacking a sistemelor informatice [20] .
  • Reading out of buffer bounds  - citire în afara bufferului alocat în memorie. Consecințele pot fi încălcări ale securității sistemului (pierderea confidențialității), comportament instabil și incorect al programului, eroridrepturile de accesla memorie[21]. Această vulnerabilitate este inclusă în lista celor mai comune și periculoase erori software[22].

• Erori la lucrul cu memoria dinamică  - eliminarea incorectă a memoriei alocate dinamic și a indicatorilor. În acest caz, alocarea de memorie pentru obiecte se realizează în timpul execuției programului [23] , ceea ce poate duce la erori de rulare. Această vulnerabilitate afectează limbajele de programare cu un nivel scăzut de abstractizare care acceptă accesul direct la memoria computerului (C, C++) [24] .
  • Un indicator atârnător [25]  este un indicator care nu se referă la un obiect valid de tipul corespunzător. Acest tip de pointer apare atunci când un obiect a fost șters (sau mutat), dar valoarea pointerului nu a fost schimbată înnull. În acest caz, indică în continuare locația de memorie în care a locuit obiectul dat. În unele cazuri, acest lucru poate determina un atacator să obțină informații confidențiale; sau, dacă sistemul a realocat deja memoria adresabilă pentru un alt obiect, un acces cu pointer suspendat poate deteriora datele aflate acolo [26] . Un subtip specific de eroare, utilizare după liber (accesarea unei zone eliberate de memorie), este o cauză comună a erorilor de program [27] , cum ar fibrowserului web [28] .
  • Acces pointer nul . Un pointer nul are o valoare specială rezervată care indică faptul că indicatorul dat nu se referă la un obiect valid [29] . Un pointer nul va provoca o excepție [30] și va bloca programul.
  • Eliberarea memoriei nealocate anterior  este o încercare de a elibera o zonă de RAM care nu este alocată în prezent (adică liberă). Cel mai adesea, aceasta se manifestă prin dubla eliberare [31] , când există o încercare repetată de a elibera memoria care a fost deja eliberată. Această acțiune poate provoca o eroare de gestionare a memoriei [32] . În C, acest lucru se întâmplă atunci când funcția liberă este apelată în mod repetatcu același pointer, fără alocare intermediară de memorie.
  • Utilizarea diferiților manageri de memorie  este o greșeală care rupe legătura dintre alocător de memorie și dealocator și utilizează instrumente diferite pentru a lucra cu un singur segment. De exemplu, în C++ folosind free pe o bucată de memorie alocată cu new sau, în mod similar, folosind delete după malloc . Standardul C++ nu descrie nicio relație între funcțiile new / delete și C memorie dinamică, deși new / delete sunt în general implementate ca malloc / wrapper-uri libere [33] [34] . Utilizarea mixtă poate provoca un comportament nedefinit [35] .
  • Pierderea unui pointer  este pierderea adresei unui fragment de memorie alocat atunci când acesta este suprascris cu o nouă valoare care se referă la o altă zonă de memorie [36] . În acest caz, memoria adresată de indicatorul anterior nu mai este accesibilă. Acest tip de eroare are ca rezultat pierderi de memorie , deoarece memoria alocată nu poate fi eliberată. În C, acest lucru se poate întâmpla atunci când reatribuiți rezultatul malloc aceluiași pointer, fără a elibera memoria între ele.

• Variabilele neinițializate  variabile care au fostdeclaratedar care nu au fost setate la o valoare cunoscută înainte de momentul în care suntVariabilele vor avea o valoare, dar, în general, greu de prezis. Vulnerabilitățile de memorie pot apărea în prezențapointerilor neinițializați („sălbatice”)[37]. Acești pointeri sunt similare în comportamentul lor cupointerii suspendați, o încercare de a le accesa în majoritatea cazurilor va fi însoțită deerori de accessau corupție de date. Cu toate acestea, este posibil să se obțină informații confidențiale care ar fi rămas în această zonă de memorie după o utilizare anterioară[38][39].

• Erorile fără memorie  sunt probleme care apar atunci când nu există suficientă memorie disponibilă pentru un anumit program.
  • Stack overflow  - programul depășește cantitatea de informații care poate fi înstiva de apeluri(indicatorul către partea de sus a stivei depășește limitele zonei permise). În acest caz, programul se blochează [40] . Cauza erorii poate firecursiuneasau o cantitate mare de alocare de memorie pentruvariabilele localedin stivă [41] .
  • heap overflow  unui program de a aloca mai multă memorie decât este disponibilă pentru acesta. Este o consecință a manipulării frecvente (Java[42]) și adesea incorecte amemoriei dinamice. În cazul unei erori, sistemul de operare va încheia cel mai potrivit proces din punctul său de vedere pentru acest proces (de multe ori cel care a provocat eroarea, dar uneori este arbitrar[43]).

Detectarea erorilor

Posibilele erori de lucru cu memorie pot fi detectate atât în ​​timpul compilării programului, cât și în timpul execuției ( depanare ).

Pe lângă avertismentele de la compilator, analizoarele de cod statice sunt utilizate pentru a detecta erorile înainte ca programul să fie construit . Acestea vă permit să acoperiți o parte semnificativă a situațiilor periculoase prin examinarea codului sursă mai detaliat decât o analiză superficială a compilatorului. Analizoarele statice pot detecta: [44] [45] [46] [47]

• Matrice în afara limitelor
• Folosind indicatoare suspendate (sau nule sau neinițializate).
• Utilizarea incorectă a funcțiilor bibliotecii
• Scurgeri de memorie din cauza manipulării greșite a pointerilor

În timpul depanării programului, pot fi utilizați manageri speciali de memorie. În acest caz, zonele de memorie „moarte” sunt create în jurul obiectelor alocate în heap, iar atunci când depanatorul intră în ele, poate detecta erori [48] . O alternativă sunt mașinile virtuale specializate care verifică accesul la memorie ( Valgrind ). Detectarea erorilor este ajutată de sistemele de instrumentare a codului , inclusiv cele furnizate de compilator (Sanitizer [49] ).

Metode de securitate

Majoritatea limbajelor de nivel înalt rezolvă aceste probleme prin eliminarea aritmeticii pointerului din limbaj, limitând capacitatea de a arunca și introducând colectarea gunoiului ca singura schemă de gestionare a memoriei [50] . Spre deosebire de limbajele de nivel scăzut , unde viteza este importantă, limbajele de nivel înalt efectuează în mare parte verificări suplimentare [51] , cum ar fi verificarea limitelor atunci când accesează matrice și obiecte [52] .

Pentru a evita scurgerile de memorie și resurse și pentru a asigura siguranța excepțiilor, C++ modern folosește pointeri inteligente . De obicei, acestea sunt o clasă care imită interfața unui pointer obișnuit și adaugă funcționalitate suplimentară [53] , cum ar fi verificarea limitelor matricelor și obiectelor, gestionând automat alocarea și dealocarea memoriei pentru obiectul utilizat. Ele ajută la implementarea idiomului de programare Resource Acquisition is Initialization (RAII), în care achiziția unui obiect este indisolubil legată de inițializarea acestuia, iar eliberarea este indisolubil legată de distrugerea sa [54] .

Când utilizați funcții de bibliotecă, ar trebui să acordați atenție valorilor returnate ale acestora pentru a detecta posibile încălcări în funcționarea lor [55] . Funcțiile de lucru cu memoria dinamică în C semnalează o eroare (lipsa memoriei libere de dimensiunea cerută) prin returnarea unui pointer nul în locul unui pointer către un bloc de memorie [56] ; C++ folosește excepții [57] . Tratarea corectă a acestor situații vă permite să evitați terminarea incorectă (anormală) a programului [58] .

Verificările limitelor când se folosesc pointeri îmbunătățesc securitatea. Astfel de verificări sunt adăugate în timpul compilării și pot încetini programele; Au fost dezvoltate extensii hardware speciale (de exemplu, Intel MPX [59] ) pentru a le accelera .

La nivelurile inferioare de abstractizare , există sisteme speciale care asigură securitatea memoriei. La nivel de sistem de operare, acesta este un manager de memorie virtuală care separă zonele de memorie disponibile pentru procesele individuale ( suport multitasking ) și facilități de sincronizare pentru a suporta multithreading [60] . Stratul hardware tinde, de asemenea, să includă unele mecanisme precum inele de protecție [61] .

Note

1. ↑ Erik Poll. Note de curs despre securitatea bazată pe limbă . - Universitatea Radboud Nijmegen, 2016. - 21 ianuarie. / „Funcțiile de limbă care distrug siguranța memoriei includ...”
2. ↑ Laszlo Szekeres, Mathias Payer, Dawn Song. SoK: Războiul etern în memorie . — 2013 IEEE Symposium on Security and Privacy, 2013. / „Erorile de corupție a memoriei în software-ul scris în limbaje de nivel scăzut precum C sau C++ sunt una dintre cele mai vechi probleme în securitatea computerelor.”
3. ↑ Fundația ISO Standard C++. Întrebări frecvente C++: Gestionarea memoriei  . isocpp.org . Preluat la 10 februarie 2022. Arhivat din original la 10 septembrie 2018.
4. ↑ Fundația ISO Standard C++. Întrebări frecvente C++: Gestionarea memoriei  . isocpp.org . Preluat la 10 februarie 2022. Arhivat din original la 10 septembrie 2018. / „În mod clar, dacă codul tău are operații noi, operații de ștergere și aritmetică a indicatorului peste tot, vei da greșelii undeva și vei obține scurgeri, indicatori rătăciți etc.” Acest lucru este adevărat, indiferent de cât de conștiincios ești cu alocările tale: în cele din urmă, complexitatea codului va depăși timpul și efortul pe care ți-l poți permite.”
5. ↑ Victor van der Veen, Nitish dutt-Sharma, Lorenzo Cavallaro, Herbert Bos. Erori de memorie: trecutul, prezentul și viitorul . — RAID'12; Amsterdam, Olanda, 2012. - 12-14 septembrie. / „… și încă se clasează printre primele 3 erori de software cele mai periculoase.”
6. ↑ Cântecul zorilor. Siguranța memoriei - Atacuri și apărări . - Berkeley CS161 Computer Security, 2015. - Primăvara. / „De fapt, după erorile de configurare, erorile de implementare sunt probabil cea mai mare clasă de erori de securitate exploatate în practică.”
7. ↑ Laszlo Szekeres, Mathias Payer, Dawn Song. SoK: Războiul etern în memorie . — 2013 IEEE Symposium on Security and Privacy, 2013. / „Această problemă există de mai bine de 30 de ani...”
8. ↑ Cântecul zorilor. Siguranța memoriei - Atacuri și apărări . - Berkeley CS161 Computer Security, 2015. - Primăvara. / "... împiedicând atacatorii să citească sau să scrie în alte locații de memorie decât cele intenționate de programator."
9. ↑ Laszlo Szekeres, Mathias Payer, Dawn Song. SoK: Războiul etern în memorie . — 2013 IEEE Symposium on Security and Privacy, 2013. / Aplicațiile scrise în limbaje de nivel scăzut precum C sau C++ sunt predispuse la aceste tipuri de erori. Lipsa siguranței memoriei... permite atacatorilor să exploateze erorile de memorie modificând cu răutate comportamentul programului sau chiar luând controlul deplin asupra fluxului de control.”
10. ↑ Laszlo Szekeres, Mathias Payer, Dawn Song. SoK: Războiul etern în memorie . — 2013 IEEE Symposium on Security and Privacy, 2013 .
11. ↑ Victor van der Veen, Nitish dutt-Sharma, Lorenzo Cavallaro, Herbert Bos. Erori de memorie: trecutul, prezentul și viitorul . — RAID'12; Amsterdam, Olanda, 2012. - 12-14 septembrie. / „Erorile de memorie au fost discutate public pentru prima dată în 1972 de către Panelul de studiu de planificare a tehnologiei securității computerelor”.
12. ↑ Victor van der Veen, Nitish dutt-Sharma, Lorenzo Cavallaro, Herbert Bos. Erori de memorie: trecutul, prezentul și viitorul . — RAID'12; Amsterdam, Olanda, 2012. - 12-14 septembrie. / „Viermele Internet a exploatat o serie de vulnerabilități, inclusiv cele legate de erori de memorie.”
13. ↑ Laszlo Szekeres, Mathias Payer, Dawn Song. SoK: Războiul etern în memorie . — 2013 Simpozionul IEEE privind securitatea și confidențialitatea, 2013.
14. ↑ Cântecul zorilor. Siguranța memoriei - Atacuri și apărări . - Berkeley CS161 Computer Security, 2015. - Primăvara.
15. ↑ Katrina Tsipenyuk, Brian Chess, Gary McGraw. Șapte regate pernicioase: o taxonomie a erorilor de securitate software . - Atelierul NIST privind instrumentele, tehnicile și valorile de asigurare a securității software, Long Beach, CA, 2005. - noiembrie.
16. ↑ Edsger W. Dijkstra. De ce numerotarea ar trebui să înceapă de la zero (EWD 831) . - Plataanstraat 5, 5671 AL NUENEN, Olanda, 1982. - 11 august. / „... folosirea celorlalte trei convenții a fost o sursă constantă de stângăcie și greșeli...”
17. ↑ Richard Jones și Paul Kelly. Verificarea limitelor pentru C . - Imperial College, 1995. - iulie. / „Un răspuns la această analiză este renunțarea la C, deoarece această lipsă de verificare eficientă este responsabilă pentru multe defecțiuni ale software-ului.”
18. ↑ John Erickson. Hacking. Arta exploatării . - Sankt Petersburg. : Simbol-Plus, 2010. - S.  139 . — ISBN 978-5-93286-158-5 .
19. ↑ John Erickson. Hacking. Arta exploatării . - Sankt Petersburg. : Simbol-Plus, 2010. - S.  142 . — ISBN 978-5-93286-158-5 .
20. ↑ David A. Wheeler. HOWTO pentru programare sigură . — Publicat v3.72. — 2015. / „Depășirile de tampon sunt o defecțiune de securitate extrem de comună și periculoasă…”
21. ↑ Enumerarea punctelor slabe comune. CWE-126: Buffer Over-read (08 decembrie 2015). Consultat la 24 noiembrie 2016. Arhivat din original la 27 septembrie 2016.  (nedefinit) / „Acest lucru se întâmplă de obicei când indicatorul sau indexul său este incrementat la o poziție dincolo de limitele tamponului...”
22. ↑ Steve Christey. 2011 CWE/SANS Top 25 cele mai periculoase erori de software . MITRE (13 septembrie 2011). Consultat la 24 noiembrie 2016. Arhivat din original la 12 aprilie 2018. (nedefinit)
23. ↑ Guy Keren. Gestionarea memoriei Unix și C/C++ pentru programatori (link indisponibil) (2001-2002). Consultat la 24 noiembrie 2016. Arhivat din original la 27 septembrie 2016.  (nedefinit)  / "Mediul de rulare definește nu numai modul în care memoria este alocată și eliberată..."
24. ↑ Robert C. Seacord. Codare sigură în C și C++ . — Addison-Wesley, 2013. — P.  162 . - ISBN 978-0-321-82213-0 .
25. ↑ Jonathan Afek, Adi Sharabani. Indicator suspendat. Distruge indicatorul pentru distracție și profit . — Watchfire Corporation, 2007.
26. ↑ Ziar de calculator. Un link către nicăieri sau un indicator rupt . Preluat la 24 noiembrie 2016. Arhivat din original la 22 iunie 2018.  (nedefinit) / "... vulnerabilități care pot fi cauzate de utilizarea greșită a indicatorilor și referințelor."
27. ↑ Enumerarea punctelor slabe comune. CWE-416: Utilizați după gratuit (08 decembrie 2015). Consultat la 24 noiembrie 2016. Arhivat din original la 18 iulie 2019.  (nedefinit) / „Referirea la memorie după ce aceasta a fost eliberată poate cauza blocarea unui program, utilizarea unor valori neașteptate sau executarea codului.”
28. ↑ Juan Caballero, Gustavo Grieco, Mark Marron, Antonio Nappa. Undangle: detectarea timpurie a indicatoarelor atârnate în vulnerabilități de utilizare după liber și dublu liber . — Institutul de software IMDEA; Madrid, Spania. / „Vulnerabilitățile „Use-after-free” cresc rapid în popularitate, în special pentru exploatarea browserelor web.”
29. ↑ comp.lang.c. Întrebarea 5.1 . Consultat la 24 noiembrie 2016. Arhivat din original la 27 septembrie 2016.  (nedefinit) / „Definiția limbajului afirmă că pentru fiecare tip de indicator, există o valoare specială...”
30. ↑ Oracol. Platforma Java, specificația API Standard Edition 7 . Consultat la 24 noiembrie 2016. Arhivat din original la 23 aprilie 2018.  (nedefinit) / „Aruns atunci când o aplicație încearcă să folosească null într-un caz în care este necesar un obiect.”
31. ↑ Enumerarea punctelor slabe comune. CWE-415: Dublu gratuit (08 decembrie 2015). Consultat la 24 noiembrie 2016. Arhivat din original la 27 septembrie 2016.  (nedefinit) / "Când un program apelează free() de două ori cu același argument..."
32. ↑ Yan Huang. Debordări de grămezi și atacuri dublu libere . Consultat la 24 noiembrie 2016. Arhivat din original la 17 aprilie 2018.  (nedefinit) / "Dacă free(p) a fost deja apelat înainte, apare un comportament nedefinit."
33. ↑ Andrei Alexandrescu. Design modern C++: programare generică și modele de proiectare aplicate . - Addison Wesley, 2001.  (link indisponibil) / „... este de obicei implementat ca un înveliș subțire în jurul alocatorului C heap...”
34. ↑ Guy Keren. Gestionarea memoriei Unix și C/C++ pentru programatori (link indisponibil) (2001-2002). Consultat la 25 noiembrie 2016. Arhivat din original la 27 septembrie 2016.  (nedefinit)  / "De exemplu, noul operator al compilatorului GNU C++ invocă de fapt funcția C runtime malloc()."
35. ↑ Managementul memoriei . Consultat la 25 noiembrie 2016. Arhivat din original la 10 septembrie 2018.  (nedefinit) / "Operatorii C++ noi și ștergeți garantează construcția și distrugerea corespunzătoare... Funcțiile în stil C... nu asigură asta."
36. ↑ OWASP. scurgere de memorie . Consultat la 25 noiembrie 2016. Arhivat din original pe 23 noiembrie 2016. (nedefinit)
37. ↑ Probleme legate de pointeri . Data accesului: 25 noiembrie 2016. Arhivat din original pe 26 februarie 2013.  (nedefinit) / „Nimic nu este mai deranjant decât indicatoarele „sălbatice”!”
38. ↑ Halvar Flake. Atacurile asupra variabilelor locale neinițializate (2006). Consultat la 25 noiembrie 2016. Arhivat din original la 3 iunie 2016.  (nedefinit) / "Ne uităm la următoarea situație atunci..."
39. ↑ Enumerarea punctelor slabe comune. CWE-457: Utilizarea variabilei neinițializate (08 decembrie 2015). Consultat la 25 noiembrie 2016. Arhivat din original la 2 octombrie 2016.  (nedefinit) / „Un atacator poate uneori să controleze sau să citească aceste conținuturi.”
40. ↑ Utilizarea și portarea GNU Fortran . James Craig, Burley (1 iunie 1991). Data accesului: 25 noiembrie 2016. Arhivat din original pe 5 octombrie 2012. (nedefinit)
41. ↑ Danny Kalev. Înțelegerea depășirii stivei (5 septembrie 2000). Data accesului: 25 noiembrie 2016. Arhivat din original pe 5 octombrie 2012.  (nedefinit) / „Cele două cauze cele mai frecvente pentru o depășire a stivei...”
42. ↑ John Boyland. Document de poziție: Gestionarea erorilor „Memorie lipsită” . — Universitatea din Wisconsin-Milwaukee, SUA. Arhivat din original pe 22 martie 2016. / „O eroare „memorie lipsită” poate fi catastrofală pentru un program, în special pentru unul scris într-un limbaj precum Java care utilizează frecvent alocarea memoriei.”
43. ↑ Mulyadi Santosa. Când Linux rămâne fără memorie (30.11.2006). Consultat la 15 noiembrie 2016. Arhivat din original la 14 aprilie 2018.  (nedefinit) / "... nu mai puteți aloca mai multă memorie și nucleul oprește o sarcină (de obicei cea care rulează curent)."
44. ↑ Anders Moller și Michael I. Schwartzbach. Analiza Programului Static . - Departamentul de Informatică, Universitatea Aarhus, 2015. - Mai.
45. ↑ Cppcheck - Un instrument pentru analiza statică a codului C/C++ . Consultat la 25 noiembrie 2016. Arhivat din original la 18 ianuarie 2016.  (nedefinit) / "Detectați diferite tipuri de erori în codul dvs...."
46. ↑ Proiecte semantice. Analiza siguranței memoriei cu CheckPointer . Consultat la 25 noiembrie 2016. Arhivat din original la 18 aprilie 2018.  (nedefinit) / „Programele cu pointeri pot comite o varietate de erori în accesarea memoriei...”
47. ↑ PVS-Studio. Analiza codului static (25.03.2015). Consultat la 25 noiembrie 2016. Arhivat din original la 25 ianuarie 2018. (nedefinit)
48. ↑ Emery D. Berger, Benjamin G. Zorn. DieHard: Siguranța probabilistică a memoriei pentru limbile nesigure . — PLDI'06; Ottawa, Ontario, Canada, 2006. 11-14 iunie.
49. ↑ Konstantin Serebryani, Dmitri Vyukov. Găsirea curselor și erorilor de memorie cu instrumente de compilare . GNU Tools Cauldron (10 iulie 2012). Consultat la 25 noiembrie 2016. Arhivat din original la 12 martie 2016. (nedefinit)
50. ↑ Erik Poll. Securitate bazată pe limbaj: limbaje de programare „sigure” (downlink) . Universitatea Radboud din Nijmegen . Consultat la 25 noiembrie 2016. Arhivat din original pe 5 noiembrie 2016.  (nedefinit)  / „Gestionarea manuală a memoriei poate fi evitată prin...”
51. ↑ Dinakar Dhurjati și Vikram Adve. Verificarea limitelor matricei compatibile cu versiunea inversă pentru C cu supraîncărcare foarte scăzută . — Departamentul de Informatică Universitatea Illinois din Urbana-Champaign. / „... o problemă nerezolvată, în ciuda unui istoric îndelungat de muncă privind detectarea încălcărilor limitelor matricei sau a depășirilor de buffer, deoarece cele mai bune soluții existente până în prezent sunt fie mult prea scumpe pentru a fi utilizate în codul de producție implementat...”
52. ↑ Bruce Eckel. Gândirea în Java. Ediția a patra . / „Atât matricele, cât și containerele garantează că nu puteți abuza de ele. Indiferent dacă utilizați o matrice sau un container, veți obține o excepție RuntimeException dacă depășiți limitele, indicând o eroare a programatorului."
53. ↑ David Kieras. Folosind indicatori inteligenti C++11 . - Departamentul EECS, Universitatea din Michigan, 2016. - Iunie. / „Indicatoarele inteligente sunt obiecte de clasă care se comportă ca indicatori încorporați, dar gestionează și obiectele pe care le creați...”
54. ↑ Microsoft Developer Network. Indicatori inteligente (C++ modern) . Consultat la 25 noiembrie 2016. Arhivat din original la 5 decembrie 2017.  (nedefinit) / „Sunt extrem de importante pentru limbajul de programare RAII sau Achiziția resurselor este inițializarea...”
55. ↑ Enumerarea punctelor slabe comune. CWE-252: Valoare de returnare neverificată (08 decembrie 2015). Consultat la 25 noiembrie 2016. Arhivat din original la 18 iulie 2019.  (nedefinit) / „Software-ul nu verifică valoarea returnată de la o metodă sau o funcție, ceea ce o poate împiedica să detecteze stări și condiții neașteptate.”
56. ↑ Microsoft Developer Network. malloc . Consultat la 25 noiembrie 2016. Arhivat din original la 5 octombrie 2016.  (nedefinit) / "malloc returnează un pointer netipizat către zona de memorie alocată sau NULL dacă nu este suficientă memorie disponibilă."
57. ↑ operator nou, operator nou[ ] . Consultat la 25 noiembrie 2016. Arhivat din original la 29 martie 2018.  (nedefinit) / "aruncă std::bad_alloc sau o altă excepție derivată din std::bad_alloc (din C++11) la eșecul alocării memoriei"
58. ↑ Paul și Harvey Deitel. C: cum se programează .
59. ↑ Zona pentru dezvoltatori Intel. Introducere în Intel® Memory Protection Extensions (16 iulie 2013). Consultat la 25 noiembrie 2016. Arhivat din original la 5 mai 2019. (nedefinit)
60. ↑ Sarah Diesburg. Protecția memoriei: kernel și spații de adrese utilizator . Consultat la 25 noiembrie 2016. Arhivat din original la 9 august 2017. (nedefinit)
61. ↑ Michael D. Schroeder și Jerome H. Saltzer. O arhitectură hardware pentru implementarea inelelor de protecție . - Al treilea simpozion ACM privind principiile sistemelor de operare, Palo Alto, California, 1971. - 18-20 octombrie.

Literatură

• Eric Poll. Note de curs despre  securitatea bazată pe limbă . - Universitatea Radboud Nijmegen, 2016. - 21 ianuarie.
• David A. Wheeler. HOWTO pentru programare sigură . - Ediția v3.72. — 2015.

Link -uri

Publicatii generale

• Laszlo Szekeres, Mathias Payer, Tao Wei, Dawn Song. SoK: Eternal War in Memory  (engleză) . - IEEE Computer Society Washington, DC, SUA, 2013. - 19-22 mai. — ISBN 978-0-7695-4977-4 . - doi : 10.1109/SP.2013.13 .
• Cântecul zorilor. Siguranța memoriei - Atacuri și apărări  (engleză) . - Berkeley CS 161 Computer Security, 2015. - Spring.
• Katrina Tsipenyuk, Brian Chess, Gary McGraw. Șapte regate pernicioase: o taxonomie a  erorilor de securitate software . - 2005. - 12 decembrie. — ISSN 1540-7993 . - doi : 10.1109/MSP.2005.159 .
• Emery D. Berger, Benjamin G. Zorn. DieHard: Siguranța probabilistică a memoriei pentru  limbile nesigure . — PLDI '06; Ottawa, Ontario, Canada, 2006. 11–14 iunie. — ISBN 1-59593-320-4 . - doi : 10.1145/1133981.1134000 .
• Eric Poll. Securitate bazată pe limbaj: limbaje de programare „sigure”  (eng.)  (downlink) . Universitatea Radboud din Nijmegen . Data accesului: 24 noiembrie 2016. Arhivat din original pe 5 noiembrie 2016.
• Victor van der Veen, Nitish dutt-Sharma, Lorenzo Cavallaro, Herbert Bos. Erori de memorie: trecutul, prezentul și  viitorul . — RAID'12; Amsterdam, Olanda, 2012. - 12-14 septembrie. - ISBN 978-3-642-33337-8 . - doi : 10.1007/978-3-642-33338-5_5 .

Publicații tematice

• Guy Keren. Gestionarea memoriei Unix și C/C++ Runtime pentru programatori  (engleză)  (link indisponibil) (2001-2002). Consultat la 24 noiembrie 2016. Arhivat din original la 27 septembrie 2016.
• Jonathan Afek, Adi Sharabani. Indicator suspendat. Distruge indicatorul pentru distracție și  profit . — Watchfire Corporation, 2007.
• Juan Caballero, Gustavo Grieco, Mark Marron, Antonio Nappa. Undangle : Detectarea timpurie a indicatoarelor atârnate în vulnerabilități de utilizare după liber și dublu liber  . — ISSTA 2012; Minneapolis, MN, SUA, 2012. - 15-20 iulie. — ISBN 978-1-4503-1454-1 . doi : 10.1145 / 2338965.2336769 .
• Yan Huang. Heap Overflows and Double-Free Attacks  (în engleză) (2016). Data accesului: 24 noiembrie 2016.
• Fulg Halvar. Atacuri asupra variabilelor locale neinițializate  . Pălărie neagră Federal (2006). Data accesului: 24 noiembrie 2016.
• John Boyland. Hârtie de poziție : Gestionarea erorilor „Memorie lipsită”  . — Atelierul ECOOP 2005 privind manipularea excepțională în sistemele orientate obiect; Universitatea din Wisconsin-Milwaukee, SUA, 2005. - iulie. Arhivat din original pe 22 martie 2016.
• David Kieras. Folosind indicatori inteligenti  C ++ 11 . - Departamentul EECS, Universitatea din Michigan, 2016. - Iunie.
• Dinakar Dhurjati, Vikram Adv. Verificarea limitelor matricei compatibile cu versiunea inversă pentru C cu supraîncărcare foarte  scăzută . — ICSE '06; Shanghai, China, 2006. 20-28 mai. — ISBN 1-59593-375-1 . - doi : 10.1145/1134285.1134309 .