Seguridad de memoria
¿Qué es Seguridad de memoria?
Seguridad de memoriaLa seguridad de memoria es la propiedad de que un programa nunca lee, escribe ni ejecuta memoria que no haya asignado legitimamente, evitando clases enteras de vulnerabilidades.
Las garantias de seguridad de memoria incluyen seguridad espacial (sin accesos fuera de limites), temporal (sin use-after-free ni double-free), de tipos e inicializacion. C y C++ no son memory safe por defecto y son la causa de la mayoria de los CVE criticos via desbordes, UAF y confusion de tipos. Datos recientes de Microsoft, Google Project Zero y el informe de la ONCD de EE. UU. (2024) atribuyen entre el 60 y el 70 por ciento de las vulnerabilidades graves en grandes bases C/C++ a errores de memoria. Las mitigaciones (ASLR, DEP, CFI, sanitizers) elevan el coste de explotacion, pero la solucion definitiva es eliminar los errores en origen con lenguajes memory safe o subconjuntos verificados formalmente.
● Ejemplos
- 01
Una escritura fuera de limites convierte un chunk del heap en un objeto controlado por el atacante.
- 02
Un use-after-free libera un objeto JavaScript cuyo puntero todavia esta en una cache del JIT.
● Preguntas frecuentes
¿Qué es Seguridad de memoria?
La seguridad de memoria es la propiedad de que un programa nunca lee, escribe ni ejecuta memoria que no haya asignado legitimamente, evitando clases enteras de vulnerabilidades. Pertenece a la categoría de Seguridad de aplicaciones en ciberseguridad.
¿Qué significa Seguridad de memoria?
La seguridad de memoria es la propiedad de que un programa nunca lee, escribe ni ejecuta memoria que no haya asignado legitimamente, evitando clases enteras de vulnerabilidades.
¿Cómo funciona Seguridad de memoria?
Las garantias de seguridad de memoria incluyen seguridad espacial (sin accesos fuera de limites), temporal (sin use-after-free ni double-free), de tipos e inicializacion. C y C++ no son memory safe por defecto y son la causa de la mayoria de los CVE criticos via desbordes, UAF y confusion de tipos. Datos recientes de Microsoft, Google Project Zero y el informe de la ONCD de EE. UU. (2024) atribuyen entre el 60 y el 70 por ciento de las vulnerabilidades graves en grandes bases C/C++ a errores de memoria. Las mitigaciones (ASLR, DEP, CFI, sanitizers) elevan el coste de explotacion, pero la solucion definitiva es eliminar los errores en origen con lenguajes memory safe o subconjuntos verificados formalmente.
¿Cómo defenderse de Seguridad de memoria?
Las defensas contra Seguridad de memoria combinan habitualmente controles técnicos y prácticas operativas, como se detalla en la definición.
¿Cuáles son otros nombres para Seguridad de memoria?
Nombres alternativos comunes: Errores de seguridad de memoria.
● Términos relacionados
- appsec№ 671
Lenguajes con seguridad de memoria
Los lenguajes con seguridad de memoria como Rust, Go, Swift, Java y C# evitan los errores espaciales y temporales de memoria que originan la mayoria de vulnerabilidades explotables en C y C++.
- appsec№ 953
Propiedades de seguridad de Rust
Rust impone seguridad de memoria y de hilos en tiempo de compilacion mediante ownership, borrowing y lifetimes, eliminando UAF y carreras de datos sin recolector de basura.
- appsec№ 217
Integridad del flujo de control
La integridad de flujo de control (CFI) restringe las llamadas indirectas y los retornos del programa a un conjunto precomputado de destinos legitimos, bloqueando ROP y JOP.
- appsec№ 064
ASLR
La aleatorización del espacio de direcciones distribuye al azar la ubicación en memoria de código, pilas, montones y librerías para impedir que un atacante prediga direcciones.
- appsec№ 303
DEP
La prevencion de ejecucion de datos (DEP / NX / W^X) marca paginas de memoria como no ejecutables para impedir que un atacante ejecute shellcode inyectado en pila o monton.
- appsec№ 925
Return-Oriented Programming
ROP es una tecnica de explotacion por reutilizacion de codigo que encadena secuencias cortas terminadas en RET para ejecutar computacion arbitraria sin inyectar codigo nuevo.
● Véase también
- № 1095Canario de pila
- № 1028Shadow stack
- № 581KASLR
- № 1058SMEP / SMAP