Utilisateur:Rayane Ad/Brouillon

Une page de Wikipédia, l'encyclopédie libre.

Définition et type de buffer-overflow[modifier | modifier le code]

Définition[modifier | modifier le code]

Un débordement de mémoire tampon(en anglais, buffer overflow) est la condition dans laquelle les informations transférées dans une mémoire tampon dépassent la capacité de stockage de cette dernière et une partie des données "déborde" (en anglais "overflow") dans une autre mémoire tampon, dans laquelle les données n'étaient pas censées circuler[1], ce qui peut corrompre les données déjà présentes dans ce tampon.

L'exploitation d'un dépassement de tampon peut entraîner une violation importante de la sécurité du système (attaque par dépassement de tampon) lorsque les conditions nécessaires sont réunies. La gravité des attaques par débordement de tampon va de l'écriture dans une autre variable, dans la mémoire d'un autre processus (défaut de segmentation), à la redirection du flux du programme pour exécuter un code malveillant.[2]

Une attaque par débordement de tampon est une attaque qui utilise des opérations de manipulation de la mémoire pour faire déborder une mémoire tampon, ce qui entraîne le plus souvent la modification d'une adresse pointant vers un code malveillant ou inattendu. En général, une attaque par débordement de tampon est une attaque sur toute sorte de donnée[3] y compris les variables et les adresses.

Grandes familles des dépassements de tampon (Buffer-Overflow)[modifier | modifier le code]

Dépassement de pile (Stack-overflow)[modifier | modifier le code]

Un dépassement de pile ou débordement de pile (en anglais: stack-overflow) est un débordement de mémoire tampon, situé sur la pile. Ce débordement peut aussi bien affecter les données adjacentes au tampon, dans le cadre de la pile, et en modifiant le contenu; perturbant aisni l’exécution du programme, mais il peut aussi corrompre des données à l'extérieur de l'espace alloué à la pile, écrasant ainsi des informations nécessaires au processus[4]. Le dépassement de pile, s'applique à toutes les piles, le plus souvent en faisant référence à la pile d’exécution.

Fichier:Stack overflow.png
Dépassement de tampon au sein de la pile d'exécution[5]

Une attaque de type dépassement de pile pourrait consister, à déborder hors du cadre de la pile d’exécution d'une fonction dans un programme, pour en modifier l'adresse de retour, et ainsi modifier le flux d’exécution du programme, pour exécuter une autre portion de code stockée préalablement[6].

Dépassement de tas (Heap-overflow)[modifier | modifier le code]

Le dépassement de tampon basé sur le tas est l'une des vulnérabilités les plus largement exploitées dans les récents incidents de sécurité[7]. Le débordement de tas(en anglais: heap-overflow) se produit lorsqu'un programme écrit des données dans un tampon, puis dépasse la limite du tampon et écrase la mémoire adjacente, allouées par le tas[8] . Les principaux débordement de tas, se produisent sur du code écrit dans des langages de programmation tel que le C et C++[9], qui pour des soucis d'efficacité ne vérifient pas les limites lorsque les programmeurs utilisent des pointeurs et des tableaux[10].

La mémoire du tas est allouée dynamiquement par un programme au moment de son exécution et contient généralement des données du programme[11], ce qui rend sa corruption dangereuse.

L'exploitation de ce type de dépassement de tampon, s'effectue en corrompant les données pour amener l'application à écraser les structures internes, telles que les pointeurs[12], mais aussi permettre l’exécution de code arbitraire ou divulguer des informations sensibles, ainsi le plus faible risque conduirait à une attaque par déni de service[13](Dos)


Différents types d'exploitation des dépassements de tampon[modifier | modifier le code]

Exécution de code malveillant[modifier | modifier le code]

Débordement sur l'adresse de retour[modifier | modifier le code]

Lorsque l'exécution du programme appelle une fonction, le cadre de la pile d’exécution est alloué avec les arguments de la fonction; l'adresse de retour, le pointeur du cadre précédent, les registres enregistrés et les variables locales de cette dernière. Dans la pile, l'adresse de retour pointe vers la prochaine instruction a exécuter après le retour de la fonction en cours. Les attaquants peuvent faire déborder un tampon sur la pile au-delà de la mémoire qui lui est allouée et modifier l'adresse de retour pour la remplacer par une autre et ainsi rediriger le flux d’exécution du programme sur une section de code précédemment injectée dont l'attaquant connaît l'adresse, comme un shellcode[14].

Longjump overflow[modifier | modifier le code]

La bibliothèque standard C fournit les fonctions "setjmp" et "longjmp" pour effectuer des sauts locaux. La fonction "setjmp" sauvegarde le contexte de pile et d'environnement[15] de la fonction appelante dans la variable de type "jmp_buf" (qui est un tableau) pour une utilisation ultérieure par la fonction "longjmp"; qui restaure le contexte de pile( contient l'adresse de la prochaine instruction a exécuter) et d'environnement, à partir de l'invocation la plus récente de la fonction setjmp[16].

Un attaquant peut déborder le "jmp_buf" avec l'adresse de son code; lorsque le programme appelle "longjmp", cela redirigera le flux d’exécution vers le code malveillant[17].

Return-oriented programming[modifier | modifier le code]

La technique Return-oriented programming(ROP), permet l’exécution de code par un attaquant, en s'affranchissant de certains mécanismes de protection contre les buffers-overflow mis en place dans les microprocesseurs et système d’exploitation, tels que la non-exécution de la pile d’exécution ou l'utilisation d'un espace d'adressage aléatoire [18].

ROP, tire son nom de l'instruction assembleur "RETN", qui quand elle est exécutée permet entre autre de retourner à l'adresse sauvegardée par le pointeur d'instruction de la pile et met à jour les registres de la pile, ce qui signifie que, dès que le flux d'exécution rencontre "RETN", le pointeur d'instruction est chargé et l'exécution continue à partir de la cellule mémoire pointée[19].

Fichier:Rop attack.png
État de la pile durant une attaque ROP[20]

Dans la ROP, chaque séquence d'instruction se terminant par l'instruction "RETN" est appelée un gadget. Si les attaquants savent où trouver les différents gadgets, ils peuvent par un dépassement de tampon dans la pile écraser l'adresse de retour et rediriger le flux vers ces gadgets et exécuter du code arbitraire[21].

Le chaînage de gadgets étant essentiellement une séquence de sauts vers des morceaux de code existants, il peut sembler impossible de l'exploiter à des fins malveillantes. Cependant, la technique ROP utilise le désalignement du code pour forger de nouvelles instructions à partir du code déjà chargé en mémoire, ce qui rend son exploitation viable[22].

Corruption ou divulgation de données[modifier | modifier le code]

Subterfuge des pointeurs[modifier | modifier le code]

Le subterfuge consiste à modifier les valeurs des pointeurs, tels que les pointeurs de fonction et de données. Les attaquants peuvent utiliser ce subterfuge dans les dépassements de piles, de tas ou d'objets contenant des pointeurs de fonction intégrés. Ce genre d'attaque est particulièrement efficace lorsque le programme utilise des méthodes pour empêcher la modification de l'adresse de retour[23].

Copie arbitraire[modifier | modifier le code]

Il existe une primitive de copie arbitraire qui peut permettre aux attaquants de modifier le flux de contrôle sans utiliser de données de contrôle externes, la fonction "strcpy" en C, peut amener à cette situation vulnérable, telle qu'en utilisant un dépassement de tampon pour modifier les pointeurs source et destination de la fonction; un attaquant peut arbitrairement copier n'importe quelle donnée d'un emplacement à un autre, et ainsi divulguer des informations propre au programme ou bien stockées dans la mémoire du système[24].

Les conditions nécessaires au succès de ce type d'attaque sont :

  • Une fonction de copie vulnérable telle qu'un utilisateur peut modifier les deux arguments (pointeur source et destination) .
  • Les données de contrôle (utiles) sont stockées dans la zone de mémoire locale .
Attaque en lecture[modifier | modifier le code]

Les attaques en lecture se produisent soit lorsqu'un utilisateur parvient à inciter un programme à renvoyer une réponse plus longue que l'espace tampon qui lui a été alloué (il s'agit alors d'une attaque par débordement de lecture), soit lorsque le programme renvoie accidentellement des données qui n'ont pas été correctement initialisées[25].

Les attaques en lecture sont une menace potentielle pour le code qui tente de fournir des services d'information à d'autres parties du code, en particulier lorsque les deux parties doivent négocier les tailles attendues des informations transmises dans un tampon partagé. Lorsqu'un côté oublie de vérifier une taille renvoyée par l'autre côté du protocole, il peut finir par lire au-delà du tampon et dans ses propres structures de données lors de la préparation d'une réponse[26].

En exploitant cette situation, un attaquant peut s'accaparer l'état de la mémoire qui peut inclure le contenu de la pile, les pointeurs de fonction et l'état interne qui est censé rester secret[27].

Mitigation et contre-mesures[modifier | modifier le code]

La meilleure manière de se protéger et d’empêcher les dépassements de tampon de se produire, en mettant en place diverses stratégies de mitigation à la fois sur le code source, le compilateur et le système d’exécution[28] .

Mitigation statique[modifier | modifier le code]

Les méthodes statiques offrent beaucoup d’avantages sur les méthodes dynamiques. Elles permettent d’obtenir certains résultats qui sont valables pour toutes les exécutions possibles du programme. Cependant, vérifier si un programme permet ou non des débordements de tampons est un problème difficile, non décidable pour le cas général[29].

Analyse lexicale[modifier | modifier le code]

L’analyse lexicale permet de reconnaître les unités lexicales du langage avant qu’elles ne forment un arbre syntaxique. Ces analyseurs sont à la recherche dans le code, de séquence d'unités lexicales considérer comme problématique[30].

Logiciels

  • Flawfinder, RATS, PScan  : sont des logiciels qui effectuent une analyse lexicale qui permet de détecter des constructions «dangereuses» dans les langages C et C++. Cette approche lui permet de trouver des débordements de tampons, des vulnérabilités de chaîne de format[31].
Vérification des pré-conditions et des post-conditions[modifier | modifier le code]

Cette analyse statique permet de vérifier si une fonction peut provoquer un débordement de tampon , en vérifiant que les variables reçues, en entrée, respectent les pré-conditions décritent par des annotations ajoutées, et aussi vérifier que le code de la fonction manipule les variables d'une manière qui assure que les post-conditions sont respectées au moment où elle se termine[32].

Logiciels

  • Splint : est un logiciel qui permet la détection de débordements de tampons et plusieurs «abus» du langage C. L’analyse se base sur des annotations que le programmeur doit souvent ajouter au déclaration des fonctions[33].
  • Cqual : est un logiciel qui effectue une analyse basée sur le typage et permet de spécifier et de vérifier des propriétés de programmes écrient en C. Il demande à l’utilisateur d’ajouter certaines annotations à quelques endroits clés dans le code source du programme à analyse[34].
Résolution de contraintes sur les chaînes de caractères[modifier | modifier le code]

Cette analyse spécifie que les chaînes de caractères sont modélisées par une paire d’entiers qui indiquent l’espace alloué pour la chaîne et sa longueur, ainsi la manipulation d'une chaîne de caractère associent des contraintes sur ces deux entiers[35].

Pour être certain qu’il n’y a pas de débordement de tampon, il faut que la borne supérieure de l’intervalle représentant la longueur de la chaîne soit plus petite ou égale à la borne inférieure de l’intervalle qui représente la quantité de mémoire allouée[36].

Mitigation dynamique[modifier | modifier le code]

Vérification niveau compilateur[modifier | modifier le code]
  • GCC Bounded Pointers : est une extension à GCC qui modifie la représentation des pointeurs de manière à permettre efficacement la vérification des bornes des tableaux à l’exécution[37].
  • Bounds Checking for C : est une extension de GCC qui permet la vérification des bornes à l’exécution sur la plupart des pointeurs sans en modifier la représentation[38].
  • StackGuard est une extension à GCC qui permet de détecter si l’adresse de retour de la pile d’exécution à été altéré par un dépassement de tampon dans la pile, en ajoutant au préalable de l’exécution du programme, une variable dite "canari" à coté de l'adresse de retour, ainsi si cette variable canari à été modifer, le programme est avorté [39] .
  • Stack Shield : permet de protéger l’adresse de retour des fonctions sur la pile, en enregistrant cette dernière sur une autre pile[40].
  • Stack-Smashing Protector (SSP): est une extension à GCC qui permet de protéger l’adresses de retour et plusieurs autres données «importantes» qui se trouvent sur la pile. Pour ce faire il utilise des "canaris" et il réordonne les variables de la pile[41] .
Correction niveau librairies et noyau[modifier | modifier le code]
  • libsafe : est une bibliothèque de remplacement pour certaines fonctions de la bibliothèque C. Elle fonctionne sous Linux et elle permet d’éviter l’écrasement de l’adresse de retour des fonctions protégées[42].
  • Linux kernel patch from Openwall Project : est un patch du noyau Linux empêche l’exécution de code sur la pile et elle modifie l’adresse utilisée pour le chargement des bibliothèques liées dynamiquement[43][44].
  • ASLR : La distribution aléatoire de l'espace d'adressage(ASLR en anglais "Address Space Layout Randomization"), permet au système d'exploitation à chaque fois qu'un nouveau processus est chargé en mémoire, de charger les différentes zones du processus (code, données, tas, pile, etc.) à des positions aléatoires dans l'espace mémoire virtuel du processus. Les attaques reposant sur la connaissance précise de l'adresse absolue du code injecté ou d'une fonction de bibliothèque sont très susceptibles d’échoués, empêchant ainsi une intrusion[45].
Outils de vérification[modifier | modifier le code]
  • Valgrind: est un outil de débogage qui permet de trouver à l’exécution les lectures et les écritures à l’extérieur de la mémoire allouée et la lecture de mémoire qui n’est pas initialisée. Il permet donc de trouver certains débordements de tampons[46].
  • Fuzz : est un fuzzer[47]; qui donne des entrées aléatoires à un programme dans le but de trouver des problèmes. Il permet de détecter de nombreux débordements de tampons.

Protection hardware[modifier | modifier le code]

NX / XD bit[modifier | modifier le code]

Les sections (pages) de mémoire du processus qui contiennent du code sont marquées comme exécutables et en lecture seule. En revanche, les zones contenant des données sont marquées comme étant en lecture/écriture et non exécutables. Les processeurs fournissent un support matériel pour vérifier cette politique lors de l'extraction des instructions de la mémoire principale[48], qui est le NX bit (en anglais No eXecute) ; qui est une technique utilisée dans les processeurs pour dissocier les zones mémoires contenant des instructions, donc exécutables, des zones contenant des données[49].

Cette technologie fait ses débuts tout d'abord sur les processeurs AMD, cette fonction a été reprise par Intel sous le nom XD bit (en anglais eXecute Disable), elle permet de faire de la protection d'espace exécutable, protégeant le système de certaines attaques utilisant des failles de dépassement de tampon[50].

DEP[modifier | modifier le code]

La contre-mesure DEP (en anglais Data Execution Prevention),notée aussi W⊕X, (W XOR X), est un mécanisme de protection destiné à rendre les pages de mémoire exclusivement exécutables ou inscriptibles. Les pages de code sont donc exécutables mais accessibles en lecture seule. Au contraire, le tas et la pile sont accessibles en écriture mais ne peuvent pas contenir de code exécutable. Il s'agit d'une protection efficace contre l'injection de code, mais non efficace contre les attaques de type ROP[51].

CET[modifier | modifier le code]

Dans l’aperçu technologique de l'application du contrôle du flux (CET en anglais Control-flow Enforcement Technology ), Intel présente deux contre-mesures pour renforcer le contrôle du flux d'exécution; à savoir une pile "fantome" (en anglais shadow stack) et l'ajout d'instructions pour vérifier les sauts indirects[52]. (en anglais indirect jump)

  • Shadow Stack: Intel propose la mise en place d'une pile annexe à la pile d'éxecution dite "fantome" compatible avec les modes USER et SUPERVISER. Pour ce faire le comportement des instructions CALL et RET est modifié[53].
    L'instruction CALL en plus de stocker l'adresse de retour dans la pile d'exécution, une copie de cette adresse sera stockée dans une pile fantôme située dans une autre section mémoire.Pour ce faire un nouveau registre appelé SSP va contenir l'adresse du sommet de la pile "fantôme"[54].
    L'instruction RET est également modifiée pour récupérer les deux adresses de retour et les comparer, si celles-ci sont différentes le processeur lève une exception[55] .
  • Indirect Branch Tracking: Cette deuxième contre-mesure consiste en l'ajout de l'instruction ENDBRANCH (ENDBR), destinée à valider les sauts indirects lors de leurs exécutions[56].
    L'instruction ENDBR est ajoutée après chaque instruction CALL et JUMP indirect, ainsi lors de l’exécution le processeur s'attend à trouver l'instruction ENDBR après les instructions de sauts, et si ce n'est pas le cas une exception est levée[57].

Chronologie anecdotique[modifier | modifier le code]

Genèse des buffer-overflows[modifier | modifier le code]

Le dépassement de tampon (en anglais buffer-overflow) est une vulnérabilité exploitée selon des anecdotes depuis les années 1960, elle commence à faire l'objet de recherche pour mettre en place des contres mesures, à la suite de la parution en août 1996, dans la 49ème édition du magazine électronique Phrack , de l'article D'Aleph One intitulé "Smashing the stack for fun and profit"[58]; qui détaille cette catégorie de faille[59] , présente dans des programmes implémentés en C, en précisant que de telles brèches sont présentes dans des programmes à usage répandu, notamment dans les systèmes d’exploitation UNIX.

Buffer-overflow les plus connus[modifier | modifier le code]

Il y'a un grand intérêt à la mitigation des failles dues à des dépassements de tampon, en effet les conséquences de leur exploitation font d'eux , l'une des failles parmi les plus vulnérables.

  • Un overflow lors de la conversion d’un integer 64 bits à un integer signé de 16 bits, provoque l'échec de la mission Mars Climate Orbiter, suite au crash 40 secondes seulement après le démarrage de la séquence de vol de la première Ariane 5 (Ariane 501) en 1996, après un développement d’un coût d'environ 7 milliards de dollars[60].
  • En 1988 quand Robert J. Morris a été la cause de la paralysie de 10% de tous les ordinateurs d’Internet quand il a propagé son ver malicieux, « l’Inet Worm », parmi les multiples failles exploitées par ce dernier, un buffer overflow a été exploité sur les serveurs "fingerd" , qui à la suite d'un dépassement de tampon au moyen de la fonction gets(), a écrasé des données critiques lui permettant d’obtenir un shell sur l’ordinateur distant[61].
  • En 2014 , plusieurs sites webs sur internet sont affectés par la faille Heartbleed, dans l'extension Heartbeat d'OpenSSL(CVE-2014-0160)[62]; qui permet à des attaquants distants d'obtenir des informations sensibles à partir de la mémoire du processus via des paquets modifiés qui déclenchent un dépassement de tampon, comme la divulgation de clé privée et de mot de passe.
  • Une vulnérabilité de débordement de tas est identifiée dans Sudo ; un utilitaire quasi omniprésent disponible sur les principaux systèmes d'exploitation de type Unix. Tout utilisateur non privilégié peut obtenir les privilèges super-utilisateur (root) sur un hôte vulnérable en exploitant cette vulnérabilité(CVE-2021-3156)[63]

Références[modifier | modifier le code]

  1. ↑ Buffer-Overflow Definition 2006, p. 1
  2. ↑ Buffer-Overflow Definition 2006, p. 1
  3. ↑ Buffer-Overflow attaque def 2006, p. 2
  4. ↑ Stack-Overflow Définition 2015, p. 2
  5. ↑ image stack_overlow 2020, p. 52
  6. ↑ Stack-Overflow Simple Attack 2012, p. 1
  7. ↑ Heap-Overflow introduction 2017, p. 1
  8. ↑ Heap-Overflow Definition 2012, p. 2
  9. ↑ Heap-Overflow C++ 2011, p. 5
  10. ↑ Heap-Overflow Definition 2012, p. 2
  11. ↑ Heap-Overflow Definition 2012, p. 2
  12. ↑ Heap-Overflow Definition 2012, p. 2
  13. ↑ Heap-Overflow introduction 2017, p. 1
  14. ↑ Overwritting the Return Addres 2012, p. 2
  15. ↑ Man page setjump 2021
  16. ↑ longjump overflow 2021, p. 2
  17. ↑ longjump overflow 2021, p. 2
  18. ↑ Return-Oriented Programming: Exploits Without Code Injection 2009
  19. ↑ Return-Oriented Programming 2012, p. 1
  20. ↑ image rop attack 2020, p. 62
  21. ↑ Return-Oriented Programming 2012, p. 2
  22. ↑ Return-Oriented Programming 2012, p. 2
  23. ↑ Pointer subterfuge 2012, p. 3
  24. ↑ Arbitrary Copy 2006, p. 4
  25. ↑ read attack 2004, p. 3
  26. ↑ read attack 2004, p. 3
  27. ↑ read attack 2004, p. 3
  28. ↑ mitigation stategy 2014, p. 3
  29. ↑ mitigation statique 2003, p. 75
  30. ↑ analyse lexicale 2003, p. 76
  31. ↑ mitigation statique logiciels 2003, p. 94-95
  32. ↑ précondition 2003, p. 77
  33. ↑ Splint 2003, p. 94
  34. ↑ Cqual 2003, p. 95
  35. ↑ contrainte chaînes de caractères 2003, p. 79
  36. ↑ contrainte chaînes de caractères 2003, p. 79
  37. ↑ GCC Bounded Pointers 2003, p. 97
  38. ↑ Bounds Checking 2003, p. 97
  39. ↑ StackGuard 2006, p. 1
  40. ↑ Stack Shield 2003, p. 97
  41. ↑ SSP 2014, p. 3
  42. ↑ libsafe 2003, p. 99
  43. ↑ Openwall 2003, p. 56
  44. ↑ Openwall kernel 2003, p. 99
  45. ↑ ASLR 2014, p. 2
  46. ↑ Valgrind 2015, p. 1
  47. ↑ fuzzer 2015, p. 2
  48. ↑ NX 2014, p. 2
  49. ↑ NX bit 2008, p. 2
  50. ↑ XD bit 2008, p. 2
  51. ↑ DEP 2020, p. 67
  52. ↑ CLE 2020, p. 68
  53. ↑ Shadow Stack 2020, p. 69
  54. ↑ Shadow Stack Call instruction 2020, p. 69
  55. ↑ Shadow Stack RET instruction 2020, p. 69
  56. ↑ Indirect Branch Tracking 2020, p. 69
  57. ↑ Indirect Branch Tracking 2020, p. 69
  58. ↑ Smashing the stack for fun and profit 1996
  59. ↑ Genèse buffer overflow 2004, p. 4
  60. ↑ Crash Ariane 5 2004, p. 4
  61. ↑ Inet Worm 2004, p. 11
  62. ↑ CVE-2014-0160 2014
  63. ↑ CVE-2021-3156 2021

Bibliographie référencée[modifier | modifier le code]

  • Document utilisé pour la rédaction de l’article (en) Iyer, Vivek and Kanitkar, Amit and Dasgupta, Partha and Srinivasan, Raghunathan, « Preventing Overflow Attacks by Memory Randomization », Expert Systems with Applications,‎ , p. 339-347 (DOI 10.1109/ISSRE.2010.22)
  • Document utilisé pour la rédaction de l’article (en) Piromsopa, Krerk and Enbody, Richard J., « Buffer-Overflow Protection: The Theory », ,,‎ , p. 454-458 (DOI 10.1109/EIT.2006.252128)
  • Document utilisé pour la rédaction de l’article (en) Piromsopa, Krerk and Enbody, Richard J., « Buffer-Overflow Protection: The Theory », ,,‎ , p. 454-458 (DOI 10.1109/EIT.2006.252128)
  • Document utilisé pour la rédaction de l’article (en) Yan, Ke and Liu, Dong and Meng, Fanzhi, « A highly automated binary software vulnerability risk evaluation method for off-by-one stack based buffer overflow », ,,‎ , p. 16-20 (DOI 10.1109/CompComm.2015.7387532)
  • Document utilisé pour la rédaction de l’article (en) Fu, Desheng and Shi, Feiyue, « Buffer Overflow Exploit and Defensive Techniques », ,,‎ , p. 87-90 (DOI 10.1109/MINES.2012.81)
  • Document utilisé pour la rédaction de l’article (en) Li, Dongfang and Liu, Zhenglin and Zhao, Yizhi, « HeapDefender: A Mechanism of Defending Embedded Systems against Heap Overflow via Hardware », ,,‎ , p. 851-856 (DOI 10.1109/UIC-ATC.2012.115)
  • Document utilisé pour la rédaction de l’article (en) He, Liang and Cai, Yan and Hu, Hong and Su, Purui and Liang, Zhenkai and Yang, Yi and Huang, Huafeng and Yan, Jia and Jia, Xiangkun and Feng, Dengguo, « Automatically assessing crashes from heap overflows », ,,‎ , p. 274-279 (DOI 10.1109/ASE.2017.8115640)
  • Document utilisé pour la rédaction de l’article (en) Kundu, Ashish and Bertino, Elisa, « A New Class of Buffer Overflow Attacks », ,,‎ , p. 730-739 (DOI 10.1109/ICDCS.2011.63)
  • Document utilisé pour la rédaction de l’article (en) Feifei, Liu, « The principle and prevention of windows buffer overflow », I,‎ , p. 1285-1288 (DOI 10.1109/ICCSE.2012.6295299)
  • Document utilisé pour la rédaction de l’article (en) Prandini, Marco and Ramilli, Marco, « Return-Oriented Programming », I,‎ , p. 84-87 (DOI 10.1109/MSP.2012.152)
  • Document utilisé pour la rédaction de l’article (en) Piromsopa, Krerk and Enbody, Richard J., « Arbitrary Copy: Bypassing Buffer-Overflow Protections », I,‎ , p. 580-584 (DOI 10.1109/EIT.2006.252213)
  • Document utilisé pour la rédaction de l’article Gay, Olivier, « Exploitation avancée de buffer overflows », arXiv preprint cs/0405073,‎ , p. 1-92
  • Document utilisé pour la rédaction de l’article (en) Anatoliy and Gordonov, S, « The cost of preventing a buffer overflow », ;,‎ , p. 1-4 (DOI 10.1109/ASEEZone1.2014.6820627)
  • Document utilisé pour la rédaction de l’article (en) Yong-Joon Park and Zhao Zhang and Gyungho Lee, « Microarchitectural Protection Against Stack-Based Buffer Overflow Attacks », I,‎ , p. 62-71 (DOI 10.1109/MM.2006.76)
  • Document utilisé pour la rédaction de l’article (en) Mouzarani, Maryam and Sadeghiyan, Babak and Zolfaghari, Mohammad, « A Smart Fuzzing Method for Detecting Heap-Based Buffer Overflow in Executable Codes », I,‎ , p. 42-49 (DOI 10.1109/PRDC.2015.10)
  • Document utilisé pour la rédaction de l’article (en) Gisbert, Hector Marco and Ripoll, Ismael, « On the Effectiveness of NX, SSP, RenewSSP, and ASLR against Stack Buffer Overflows », I,‎ , p. 145-152 (DOI 10.1109/NCA.2014.28)
  • Document utilisé pour la rédaction de l’article (en) Sharp, Brian L. and Peterson, Gregory D. and Yan, Lok Kwong, « Extending Hardware Based Mandatory Access Controls for Memory to Multicore Architectures », .,‎ (ISBN 9781605580982, DOI 10.1109/NCA.2014.28)
  • Document utilisé pour la rédaction de l’article (en) Tuck, N. and Calder, B. and Varghese, G, « Hardware and Binary Modification Support for Code Pointer Protection From Buffer Overflow », .,‎ , p. 209-220 (DOI 10.1109/MICRO.2004.20)
  • Document utilisé pour la rédaction de l’article (en) Michaël Timber, « Protections des processeurs contre les cyber-attaques par vérification de l’intégrité du flot d’exécution », Cryptographie et sécurité [cs.CR]. Institut Polytechnique de Paris,‎ (DOI NNT: 2020IPPAT028)
  • Document utilisé pour la rédaction de l’article (en) Wang, Zhilong and Ding, Xuhua and Pang, Chengbin and Guo, Jian and Zhu, Jun and Mao, Bing, « To Detect Stack Buffer Overflow with Polymorphic Canaries », .,‎ , p. 243-254 (DOI 10.1109/DSN.2018.00035)
  • Document utilisé pour la rédaction de l’article (en) Shehab, Doaa Abdul-Hakim and Batarfi, Omar Abdullah, « RCR for preventing stack smashing attacks bypass stack canaries », .,‎ , p. 795-800 (DOI 10.1109/SAI.2017.8252186)
  • Document utilisé pour la rédaction de l’article (en) Zolotarev, Vyacheslav and Doronina, Daria, « Memory Obfuscation by Stack Randomization for Android Applications », .,‎ , p. 1-5 (DOI 10.1109/ICAICT.2017.8687250)
  • Document utilisé pour la rédaction de l’article (en) Kumar, K. Shiva and Kisore, N. Raghu, « Protection against Buffer Overflow Attacks through Runtime Memory Layout Randomization », .,‎ , p. 184-189 (DOI 10.1109/ICIT.2014.57)
  • Document utilisé pour la rédaction de l’article (en) Zhou, Hongwei and Kang, Keda and Yuan, Jinhui, « HardStack: Prevent Stack Buffer Overflow Attack with LBR », .,‎ , p. 888-892 (DOI 10.1109/ICICAS48597.2019.00191)
  • Document utilisé pour la rédaction de l’article (en) Ozdoganoglu, H. and Vijaykumar, T.N. and Brodley, C.E. and Kuperman, B.A. and Jalote, A., « SmashGuard: A Hardware Solution to Prevent Security Attacks on the Function Return Address », .,‎ , p. 1271-1285 (DOI 10.1109/TC.2006.166)
  • Document utilisé pour la rédaction de l’article (en) Hovav Shacham and Erik Buchanan and Ryan Roemer and Stefan Savage, « Return-Oriented Programming: Exploits Without Code Injection »,
  • Document utilisé pour la rédaction de l’article PATRICE LACROIX, « Les débordements de tampons et les vulnérabilités de chaîne de format », (DOI Rapport de recherche DIUL-RR-0304), p. 1-120

Voir aussi[modifier | modifier le code]

Liens externes[modifier | modifier le code]

Ce document provient de « https://fr.wikipedia.org/w/index.php?title=Utilisateur:Rayane_Ad/Brouillon&oldid=189614766 ».