¿Cómo puedo asegurarme de que toda la RAM se redujo a cero? ¿El reinicio (autoprueba de encendido) borra toda la memoria antes de que se inicie el sistema? ¿O una memoria de cero del núcleo de Linux antes de continuar?
Estoy familiarizado con ataque de arranque en frío y contramedida TRESOR . Simplemente me interesan otras formas menos complejas de limpiar la memoria.
Durante la POST , el BIOS realiza tradicionalmente una "prueba de memoria" que implica escribir y releer La totalidad de la memoria RAM física. Sin embargo, este proceso puede tomar una cantidad de tiempo no despreciable, y es bastante malo en la detección de memoria defectuosa (solo detecta de manera confiable muy mala memoria), por lo que en muchos casos está deshabilitado (por el proveedor de la computadora , o el usuario). Por lo tanto, uno debe asumir que los restos de los contenidos de la RAM antes del último arranque aún pueden persistir; la cantidad de datos que queda depende de la tecnología RAM, el tiempo de apagado antes del nuevo arranque y la temperatura.
El kernel de Linux, como la mayoría de los sistemas operativos modernos (incluido Windows, excluyendo a Windows de la línea "95"), pone a cero las páginas de RAM antes de entregarlas a las aplicaciones. Por lo tanto, si bien los contenidos físicos de la RAM pueden contener restos interesantes de datos pasados, solo se puede acceder al código del kernel; userland solo ve ceros.
En Tails lo hace
Aparte de eso, no conozco ningún otro sistema operativo popular que lo haga de manera predeterminada, por lo tanto, si alguien inserta su memoria RAM se adhiere a algún tipo de sistema operativo escrito con el fin de espiar sus datos (es probable que tenga que ser una esencialmente un kernel hecho a medida para evitar cualquier operación de escritura en la RAM) podrían obtener toda esa memoria dulce y jugosa.
Gracias a Thomas Pornin por la sugerencia de que las aplicaciones en modo de usuario no pueden acceder a la RAM en bruto.
Reinicia no, ya no.
Hoy en día, los sistemas están diseñados para poder sostener el contenido de RAM muy bien para standby / sleet / hibernate o cualquier tipo de estado suspendido y para otros propósitos como discos RAM persistentes. A menos que el software haga cosas especiales para borrar el contenido de la RAM (como hace TrueCrypt si ejecuta truecrypt / wipecache), los datos seguirán allí hasta que se sobrescriban.
En cuanto a un procedimiento de desconexión de la alimentación, entonces sí, el contenido de RAM se borra, bastante rápido para DDR3 y superior, por lo que prácticamente se queda en blanco a menos que el sistema esté diseñado con algún tipo de batería de respaldo integrada (como para algunos sistemas de almacenamiento o servidores).
Ahora, si intencionalmente deseas borrar la memoria RAM sin tener que usar medios bárbaros como desenchufar, puedes arrancar un memtest y lo limpiará muy bien para ti.
También usé en sistemas operativos tempranos una forma diferente para propósitos de prueba: tengo un archivo de prueba (con datos aleatorios o solo un carácter que se repite), tan grande como la RAM del sistema. Lo abro para editarlo con un editor que carga todo el archivo en la RAM. En un punto, habrá un error de salida de RAM. Cierro el editor y continúo mi trabajo.
La memoria no se borra al reiniciar (probado en Macbook). Puede verificar esto trivialmente en Linux ejecutando un programa, reiniciando para que el programa ya no se ejecute, y luego grep en /dev/mem para el hash de las cadenas contenidas en la memoria del programa. Por ejemplo:
Iniciar sesión como root entonces
# sums=$(strings /dev/mem | while read s; do echo $s | sha256sum; done)
# echo "${sums}" | grep 79b4f11b6ccf3a7c397fbfd032672c65d825bdb38eae1aa445183b0b3934be6b
Esto calcula la suma de comprobación sha256 de todas las cadenas en la memoria. Luego, las sumas de comprobación se registran para la suma de comprobación sha256 producida por echo THUNAR_ZOOM_LEVEL | sha256sum . THUNAR_ZOOM_LEVEL es una cadena de configuración de / usr / bin / thunar (thunar es un administrador de archivos para el escritorio XFCE). Dado que este arranque de Linux estaba en modo de usuario único, Xorg no se ejecutará y no se habrá iniciado ninguna aplicación X, por lo que esta cadena no proviene del arranque actual. Las cadenas de aplicación Xorg en la memoria se conservaron del inicio anterior.
Si vuelcas /dev/mem con dd o ejecutas strings en él, verás la memoria de todos los programas gráficos que se ejecutaban en la GUI: programas que se ejecutaban antes del reinicio pero no se ejecutan modo de usuario único.
En las máquinas virtuales parece que la memoria no se borra. En IncludeOS (includeos.org) usamos esto para almacenar datos de fallos en la memoria (ya que la pila de IP y el sistema de IO podrían no ser funcionales) y recoger el informe de fallos después de reiniciar el sistema.
Hemos probado esto en qemu / kvm y Vmware ESXi. No hemos probado en metal desnudo.
Lea otras preguntas en las etiquetas data-leakage memory