¿Se está borrando la memoria en el código / finalizar las buenas prácticas?

1

A veces las contraseñas / hash / keys & otra información privada se almacena en variables y, por lo tanto, en la memoria / RAM durante la ejecución del código.

mientras que algunas situaciones (es decir, Kernels de Linux, vea aquí ¿Hay algún parche de distribución o kernel de Linux que borre el espacio de la memoria del proceso después de la ¿salidas de proceso? ) preocuparse por borrar la memoria usada Me preguntaba más acerca de la imagen más amplia:

La pregunta es por lo tanto: ¿Debería el programador de código preocuparse por la limpieza (es decir, la puesta a cero) de la información sensible por él mismo? Más preciso debería hacer algo como esto

int main()
{
    char bufferWithSecret [10];
    sprintf (bufferWithSecret, "%d",generateKey());

    // do some stuff
    // ...
    // ...

    sprintf (bufferWithSecret, "000000000"); // wipe the memory
}
    
pregunta humanityANDpeace 24.04.2014 - 12:37
fuente

2 respuestas

5

Si borra la información confidencial antes, podría posiblemente reducir la ventana de tiempo para un exploit mientras su programa se está ejecutando, pero en general (y en particular en un contexto cuando sale-proceso-salidas) es un esfuerzo bastante inútil.

Es mucho más importante para bloquear la memoria que contiene datos confidenciales, por lo que no se puede intercambiar. La información confidencial que se intercambia es algo que debe evitar a toda costa.
Lo peor de una página con datos confidenciales que se intercambian es, por cierto, ni siquiera el hecho de que se haya escrito en el disco, sino el hecho de que no se puede garantizar que se volverá a eliminar del disco (debido al desgaste de las unidades). -arrasamiento). Esto está totalmente fuera del control del sistema operativo, o incluso de su aplicación.

Las páginas de memoria se ponen a cero antes de pasar a un nuevo proceso en todos los sistemas operativos que no son bromas, por lo que ponerlas a cero manualmente no agrega nada (no en un modelo de amenaza realista , de todos modos). br> Por supuesto, alguien podría usar un exploit DMA (como Firewire) para leer páginas RAM físicas que no se han borrado, pero ya podrían hacerlo mientras su programa se está ejecutando, en la medida en que no se gane mucho borrándolas un poco antes. p>     

respondido por el Damon 24.04.2014 - 12:51
fuente
1

No, no debes hacer algo "así". Debería utilizar una función de biblioteca destinada a borrar datos confidenciales.

El problema con el uso de rutinas de propósito general como sprintf , memset o su propio bucle es que el compilador puede realizar un análisis de dependencia de los datos, determinar que el nuevo valor no es importante y optimizar la escritura.

Windows proporciona una función SecureZeroMemory por exactamente este motivo. Algunos marcos lo hacen muy fácil, otros no. Puede consultar esta pregunta para obtener más información:

Finalmente, solo existe SecureZeroMemory y .NET SecureString porque esta es una buena práctica.

    
respondido por el Ben Voigt 01.05.2014 - 21:56
fuente

Lea otras preguntas en las etiquetas