¿Cómo pueden los problemas de memoria conducir a explotaciones de ejecución de código?

1

En los informes sobre vulnerabilidades / vulnerabilidades de seguridad en aplicaciones de escritorio, a menudo leo que los problemas de memoria llevan a la ejecución de código malicioso.

Por ejemplo, la descripción de vulnerabilidad de Internet Explorer CVE-2018-8653 dice ( enlace )

  

La vulnerabilidad podría dañar la memoria de tal manera que un atacante podría ejecutar código arbitrario

¿Cómo funciona esto en general?

Por lo que yo entiendo, los problemas de este tipo tienen en común que en una aplicación de escritorio / la asignación de memoria de proceso no se realizó correctamente, es decir, hay algo en la memoria donde no debería o al revés: Debería haber algo allí, pero no lo es. Hasta aquí todo mal. Los problemas de este tipo casi siempre conducen a un mal funcionamiento de los programas o fallos. Pero, ¿cómo puede un atacante usar ese problema para inyectar / ejecutar código?

    
pregunta cis 20.12.2018 - 16:24
fuente

2 respuestas

1

La memoria que utiliza un programa incluye tanto lo que usted consideraría como "datos" (el texto que escribió, la imagen que está viendo, el código fuente de la secuencia de comandos que descargó su navegador web, una cadena de texto que se está construyendo con esa información). script ...), lo que podría considerarse como "metadatos" (una asignación de bloques de memoria libres y usados, punteros al inicio de esos bloques de memoria, punteros que enlazan esa cadena de texto con las funciones que pueden ejecutarse en él, punteros a bibliotecas cargadas como jscript.dll de IE que analiza y compila JavaScript) y código ejecutable (el código binario real que ejecuta la CPU, incluido el contenido de la DLL, el resultado de compilar el JS y las funciones en "objetos" en los datos) .

Cuando se produce un daño en la memoria, un atacante generalmente puede ejercer cierto control sobre dónde y cómo ocurre. Por ejemplo, si el atacante encuentra la manera de eliminar algunos datos, pero el programa para tratarlos como si estuvieran presentes (lo que se conoce como una vulnerabilidad de "uso después de la libertad" y relativamente común en los motores de JavaScript), el script del atacante podría crear una El nuevo objeto de datos (como una matriz de bytes elegidos con cuidado) que tiene un tamaño similar y se creará en el mismo lugar que el objeto eliminado pero aún utilizable. El atacante puede establecer algún valor en el objeto eliminado, pero como la memoria que lo define tiene ahora algunos datos totalmente nuevos (la matriz creada por el atacante), en realidad cambia algún valor que el atacante no debe poder controlar. tales como la extensión de la matriz. Luego, el atacante usa la matriz, que el programa ahora piensa que es muy larga, se extiende mucho más allá de la porción de memoria asignada en la que realmente está almacenada en la memoria utilizada para otras cosas, y hace algo como cambiar los metadatos del "puntero de retorno" que dice "cuando este bloque de código termine, continúe ejecutando el código aquí". El atacante cambia el puntero de retorno para que el código que se ejecutará después de que finalice la función actual haga algo como lanzar un programa que el atacante escribió, ejecutando un código arbitrario en la computadora de la víctima.

Este tipo de ataque (usar después de ganar para obtener una lectura / escritura de memoria de compensación arbitraria, usar eso para sobrescribir la dirección de retorno en alguna función deseada por el atacante) es una de las muchas formas de explotar la corrupción de la memoria. . Algunas otras vulnerabilidades de corrupción de memoria son de doble libre (intentar eliminar el mismo bloque de memoria dos veces, lo cual es peligroso porque puede terminar tratando los datos controlados por el atacante como si fueran realmente metadatos sobre las asignaciones de memoria y, por lo tanto, cambiar los datos que el usuario debería No tenga acceso a), desbordamientos de búfer en la pila o el montón (dos datos de programas de lugares diferentes van a la pila, donde también encontrará cosas como punteros de retorno y el montón donde encontrará cosas como tablas de funciones y arbitrarias arrays de longitud) donde puede escribir más allá del final de una asignación de memoria y cambiar otros datos, desbordamiento de enteros donde el programa hace algunos cálculos matemáticos en dos números que terminan con un resultado demasiado grande para que el programa se mantenga en el espacio reservado para eso número, por lo que pierde parte de ese número y trata el número totalmente diferente como un puntero en una memoria segura cuando en realidad podría ser cualquier cosa, y así sucesivamente.

    
respondido por el CBHacking 21.12.2018 - 13:10
fuente
0

Un escenario: el atacante elige un fragmento de código de shell o secuencia de llamadas del sistema que desea ejecutar, luego utiliza Metasploit, o marcos similares, para generar una carga binaria para la CPU objetivo. Luego, el atacante alimenta la carga útil al servicio de red o a la API local. Suponiendo que la validación del tamaño de entrada se rompe y no rechazó los datos de entrada, el búfer que contiene los datos de entrada se desbordará del búfer a la pila y sobrescribirá la dirección de retorno a la función de llamada. Metasploit ha creado la carga útil de manera que la nueva dirección de retorno ahora apunta a una llamada del sistema seleccionada y el código de shell se enviará a la llamada del sistema. Es posible ya que las llamadas de los sistemas siempre están en direcciones predefinidas y conocidas.

    
respondido por el barbazoo 21.12.2018 - 04:50
fuente

Lea otras preguntas en las etiquetas