Poner bruscamente, sí, podrían. Esa es la respuesta masivamente simplificada.
La respuesta más complicada es que necesita comprender cómo su sistema operativo maneja la memoria. Es posible que escuche hablar de anillos, niveles de privilegios, etc. Permítame explicarlo brevemente:
- Cuando se inicia el sistema operativo (se pasa todo el BIOS de 16 bits), básicamente tiene un montón de memoria (toda la RAM) para trabajar y lo hace en un modo privilegiado, lo que significa que puede hacer lo que sea Le gusta a cualquier parte de la memoria.
- Sin embargo, las arquitecturas x86 desde 1980, algo antes de que yo naciera, eran compatibles con el concepto de modo protegido, donde el hardware de la CPU proporciona mecanismos para permitir que el sistema operativo inicie aplicaciones de forma tal que sus direcciones de memoria estén segregadas.
- Por lo tanto, este modo protegido permite al sistema operativo la capacidad de crear un espacio de direcciones virtuales para cada aplicación. Lo que esto significa es que el concepto de memoria de una aplicación no es lo mismo que las direcciones de memoria física real y que la aplicación no tiene acceso privilegiado a la memoria. De hecho, se evita directamente que las aplicaciones modifiquen las direcciones de memoria de las demás porque no pueden verlas, excepto a través de solicitudes bien definidas al sistema operativo (syscalls) para solicitudes de cosas como memoria compartida, donde dos los procesos comparten un espacio de direcciones.
(esto es una simplificación y me estoy saltando grandes porciones por brevedad, pero eso es lo esencial: las aplicaciones tienen sus solicitudes para acceder a la memoria administrada por el sistema operativo y el hardware).
Teóricamente, estás bien, ¿verdad? No es técnicamente cierto. Como dije, los sistemas operativos proporcionan formas bien definidas de acceder a la memoria de otros procesos. En cuanto a las posibilidades, aquí está cómo algunos podrían presentar:
- Si vuelco la memoria de la aplicación , puedo resolver la contraseña almacenada con bastante facilidad.
- Un debugger o un rootkit de estilo de usuario diseñado apropiadamente podría brindarme acceso a esa memoria. No soy un experto en tales técnicas, pero sé que puede hacerse bajo ciertas circunstancias.
- Finalmente, el sistema operativo puede ser contraproducente aquí. La memoria virtual a la que tiene acceso tiene otras consecuencias. Los sistemas operativos lo presentan como virtual porque a menudo intercambian memoria para garantizar que haya suficiente RAM disponible para las aplicaciones actualmente en ejecución. Por lo tanto, un ataque interesante podría ser hacer que el sistema se intercambie, luego bloquearlo y examinar la partición de intercambio. ¿Su intercambio está encriptado también?
Finalmente, debo señalar que si su atacante está ejecutando código en el kernel a través de un módulo del kernel, el juego termina de todos modos, ya que no hay nada que los detenga en su espacio de memoria en busca de cadenas ascii.
Sin embargo, para ser realista:
- Si su kernel está comprometido a través de un rootkit, un keylogger es probablemente más fácil de implementar que algo diseñado para escanear la memoria en términos de agarrar sus contraseñas.
- Los rootkits de estilo Userland que involucran a los depuradores para evaluar programas que no están diseñados para ser depurados (es decir, sin símbolos de depuración, etc.) no serán fáciles de implementar, incluso si son teóricamente posibles. Tampoco es fácil explotar esto: usted, el usuario, tendría que ser engañado para ejecutar dicho editor bajo el depurador, lo que probablemente implique ingeniería social o acceso físico.
Sin embargo, mi recomendación es que nunca almacene contraseñas de texto simple en ningún lugar. Si necesita un recordatorio, le sugiero que utilice un indicador incompleto parcial que le refrescará la memoria y le permitirá deducir las contraseñas, pero evitará razonablemente que otras personas lo hagan, incluso si lo conocen. Esto está muy lejos de ser ideal, pero es mejor que las contraseñas de texto simple.