¿Se puede usar Heartbleed para obtener memoria de otros procesos?

Hay un análisis bien escrito en enlace completo con ejemplos de código .

El autor, Sean Cassidy , señala que (el énfasis es mío):

  

¿Qué pasa si el solicitante realmente no proporcionó bytes de carga útil, como ella?   dijo que lo hizo? ¿Qué pasa si pl realmente es sólo un byte? Entonces la lectura de   memcpy leerá cualquier memoria que esté cerca del registro SSLv3.

     

Y al parecer, hay muchas cosas cerca.

     

Para ser honesto, me sorprende un poco las afirmaciones de las personas que   Encontró la vulnerabilidad de Heartbleed. Cuando me enteré, pensé   Ese 64KB no era suficiente para buscar cosas como claves secretas. El montón   al menos en x86, crece, por lo que pensé que pl simplemente leería en   memoria recién asignada, como bp. Llaves y similares serían   asignado anteriormente, por lo que no sería capaz de leerlos. Por supuesto,   Con las implementaciones modernas de Malloc, esto no siempre es cierto.

     

Y además, no podrá leer la memoria de ningún otro proceso, por lo que esos "documentos críticos para el negocio" deberían estar en   Memoria del proceso, menos de 64 KB, y estar cerca.

Un punto de vista alternativo desde Erik Cabetas de Incluir seguridad , comentando en Reddit:

  

Estaba teniendo algunas discusiones con mi amigo sobre este error. Él piensa   Es explotable mediante el uso de una variedad de asignaciones de tamaño específico   a través del montón para leer los fragmentos de 64k alrededor de los fragmentos del montón,   no en un tipo lineal de moda que Sean en el enlace de OP implica.   Después de pensar en la forma en que ptmalloc / linux asigna, creo que esto es   posible seguro Los chicos .fi de codenomicron son tipos agudos, yo   Apuesto a que fueron capaces de obtener las asignaciones justo en un laboratorio   medio ambiente.

Editar: Sean ha actualizado :

  

Y al parecer, hay muchas cosas cerca.

     

Hay dos formas en que la memoria se asigna dinámicamente con malloc (en   menos en Linux): usando sbrk y usando mmap. Si la memoria es   asignado con sbrk, entonces usa las antiguas reglas de crecimiento de pila y   Limita lo que se puede encontrar con esto, aunque múltiples solicitudes.   (especialmente al mismo tiempo) todavía podría encontrar algunas cosas divertidas.

     

Sin embargo, si se usa mmap, todas las apuestas están desactivadas. Cualquier memoria no en uso   Podría asignarse para mmap. Esto es lo que la mayoría de los ataques.   contra Heartbleed apuntará.

     

Y la mejor parte: cuanto más grande sea el bloque solicitado, más probablemente   debe ser servido por mmap en lugar de sbrk.

Para agregar en la respuesta de @ scuzzy-delta: por definición, el exceso de búfer en el código aplicativo afecta solo al código aplicativo. El sistema operativo mantiene el aislamiento entre los distintos procesos y no permitirá que un proceso acceda al espacio de memoria de otro proceso.

Si la saturación del búfer es de la persuasión de "escritura" (el atacante obliga al objetivo a escribir bytes más allá del final del búfer), entonces esto puede convertirse en un secuestro hostil, en el que el el atacante toma el control de la aplicación de destino y hace que haga su oferta. Los privilegios en el nivel de la aplicación ya son suficientes para realizar un daño considerable, como leer (por ejemplo) todo el perfil del navegador, capturar el contenido de la pantalla y las entradas del teclado, y así sucesivamente (cuando ocurre en el lado del "cliente", por ejemplo, en un navegador ). Sin embargo, en este caso, la vulnerabilidad "de corazón" es una saturación de "lectura", que revela datos pero no afecta al sistema de destino. Esto excluye el riesgo inmediato de un secuestro hostil y sus terribles consecuencias.

However...

La obtención de secretos de la memoria aplicativa del proceso objetivo puede ser aprovechada para un ataque más extenso. Por ejemplo, si el objetivo es un servidor web, el problema del corazón puede revelar (con la cantidad adecuada de suerte) los nombres y contraseñas de algunos otros usuarios, que luego se pueden usar para iniciar sesión como estos usuarios. Esto puede ser problemático.

Para un navegador web, es decir, en el lado del cliente, se puede observar que algunos tienen la costumbre de lanzar distintas instancias de proceso, para evitar problemas de fragmentación de la memoria en sesiones de larga duración, y también para evitar perder todo el navegador cuando el complemento Flash falla. Sin embargo, no todos los navegadores hacen eso, e incluso para aquellos que lo hacen, no lo hacen de manera sistemática. Siguen las heurísticas para agrupar pestañas "juntas" en un solo proceso.

Un punto adicional es que este proceso a menudo usa algo de memoria compartida para intercambiar parte de la información necesaria, en particular la contraseña y los cachés de cookies, y las sesiones SSL. Precisamente el tipo de datos jugosos que el atacante desea obtener.

En el lado positivo, atacar al cliente requiere que el servidor con el que el cliente habla se ejecute el ataque. No puede ser iniciado por el atacante; debe esperar a que los clientes se conecten.