Securite memoire
Qu'est-ce que Securite memoire ?
Securite memoireLa securite memoire est la propriete qu'un programme ne lise, n'ecrive ni n'execute jamais une memoire qu'il n'a pas legitimement allouee, ce qui supprime des classes entieres de vulnerabilites.
La securite memoire couvre la securite spatiale (pas d'acces hors limites), temporelle (pas d'use-after-free ni double-free), de typage et d'initialisation. C et C++ ne sont pas memory safe par defaut, ce qui explique la majorite des CVE critiques via debordements, UAF et confusion de types. Les donnees recentes de Microsoft, Google Project Zero et du rapport ONCD 2024 des Etats-Unis attribuent 60 a 70 pour cent des vulnerabilites critiques des grandes bases C/C++ a des bugs memoire. Les mitigations (ASLR, DEP, CFI, sanitizers) augmentent le cout d'exploitation, mais seule l'elimination a la source via des langages memory safe ou des sous-ensembles formellement verifies offre une solution definitive.
● Exemples
- 01
Une ecriture hors limites transforme un chunk de tas en objet controle par l'attaquant.
- 02
Un use-after-free libere un objet JavaScript dont le pointeur reste dans un cache JIT.
● Questions fréquentes
Qu'est-ce que Securite memoire ?
La securite memoire est la propriete qu'un programme ne lise, n'ecrive ni n'execute jamais une memoire qu'il n'a pas legitimement allouee, ce qui supprime des classes entieres de vulnerabilites. Cette notion relève de la catégorie Sécurité applicative en cybersécurité.
Que signifie Securite memoire ?
La securite memoire est la propriete qu'un programme ne lise, n'ecrive ni n'execute jamais une memoire qu'il n'a pas legitimement allouee, ce qui supprime des classes entieres de vulnerabilites.
Comment fonctionne Securite memoire ?
La securite memoire couvre la securite spatiale (pas d'acces hors limites), temporelle (pas d'use-after-free ni double-free), de typage et d'initialisation. C et C++ ne sont pas memory safe par defaut, ce qui explique la majorite des CVE critiques via debordements, UAF et confusion de types. Les donnees recentes de Microsoft, Google Project Zero et du rapport ONCD 2024 des Etats-Unis attribuent 60 a 70 pour cent des vulnerabilites critiques des grandes bases C/C++ a des bugs memoire. Les mitigations (ASLR, DEP, CFI, sanitizers) augmentent le cout d'exploitation, mais seule l'elimination a la source via des langages memory safe ou des sous-ensembles formellement verifies offre une solution definitive.
Comment se défendre contre Securite memoire ?
Les défenses contre Securite memoire combinent habituellement des contrôles techniques et des pratiques opérationnelles, comme détaillé dans la définition ci-dessus.
Quels sont les autres noms de Securite memoire ?
Noms alternatifs courants : Bugs de securite memoire.
● Termes liés
- appsec№ 671
Langages memory safe
Les langages memory safe comme Rust, Go, Swift, Java et C# empechent les erreurs memoire spatiales et temporelles qui causent la majorite des vulnerabilites exploitables en C et C++.
- appsec№ 953
Proprietes de securite de Rust
Rust applique la securite memoire et de threads a la compilation via ownership, borrowing et lifetimes, eliminant use-after-free et data races sans ramasse-miettes.
- appsec№ 217
Integrite du flot de controle
L'integrite du flot de controle (CFI) restreint les appels indirects et les retours du programme a un ensemble precalcule de cibles legitimes, bloquant ROP et JOP.
- appsec№ 064
ASLR
La randomisation de l'espace d'adressage place aleatoirement le code, les piles, les tas et les bibliotheques en memoire afin qu'un attaquant ne puisse pas predire les adresses cibles.
- appsec№ 303
DEP
La prevention d'execution des donnees (DEP / NX / W^X) marque les pages memoire comme non executables pour empecher un attaquant d'executer du shellcode injecte dans la pile ou le tas.
- appsec№ 925
Return-Oriented Programming
Le ROP est une technique d'exploitation par reutilisation de code qui enchaine de courtes sequences terminees par RET pour executer un calcul arbitraire sans injecter de code.
● Voir aussi
- № 1095Canari de pile
- № 1028Shadow stack
- № 581KASLR
- № 1058SMEP / SMAP