¿Ayuda para comprender el bloqueo de una aplicación, explotable?

11

Como soy nuevo en la investigación de vulnerabilidades en aplicaciones nativas (a diferencia de las aplicaciones web), tengo dificultades para comprender un bloqueo en el navegador de Debian, Epiphany (versión 2.30.6), y para determinar si es explotable.

Descubrí que el siguiente código HTML + CSS provoca un bloqueo en Epiphany, cuando ocurre un redireccionamiento a otra página:

<!DOCTYPE html>
<html>
<head>
<style type="text/css">
::-webkit-scrollbar-thumb {
   height:0;
}
::-webkit-scrollbar {
   overflow:visible;
}
</style>
<meta http-equiv="Refresh" content="1; http://www.example.com/" />
</head>
<body></body>
</html>

Hasta ahora, he estado tratando de aprender sobre él y determinar su explotabilidad utilizando GDB y Valgrind .

GDB, la mayoría de las veces, informa un error de segmentación o en una dirección que cambia cada vez que lo ejecuto. También lo he visto reportar SIGILL en lugar de SIGSEGV, pero es raro. Depurando más, descubrí que esto está siendo causado por una instrucción CALL [edx + 0x228] . El valor del registro edx en el momento en que esta instrucción se ejecuta cambia ligeramente en cada ejecución, pero, según el mapa de memoria, siempre está dentro del montón.

Valgrind informa una Lectura no válida de tamaño 4 , [...] 3 bytes después de un bloque de tamaño 61 libre , justo antes de un Salto a la dirección no válida indicada en la siguiente línea y, finalmente, la falla de segmentación.

Para mí, parece un error de uso después de libre. Me gustaría que alguien confirme que tengo razón.

Suponiendo que esto es, de hecho, un uso después de libre, sé que el error podría ser explotable. Sin embargo, nunca logré sobrescribir la memoria en la dirección que resulta de la expresión edx + 0x228 y, por lo tanto, no puedo controlar el puntero de instrucción.

Creo que la razón de esto es porque el objeto se está liberando justo después de que se inicie el redireccionamiento de la página, por lo que no puedo sobrescribir el espacio en la memoria que estaba ocupando con Javascript que se ejecuta cuando se carga la página. He intentado agregar un spray de pila a window.onunload , sin embargo, agregar este método (con cualquier tipo de código en el interior) en realidad evita que ocurra el bloqueo.

Básicamente, mis preguntas son:

  1. ¿Es realmente un error de uso después de liberarse?
  2. Si es así, ¿cómo puedo determinar cuándo se está liberando el objeto y, por lo tanto, intentar averiguar si es posible sobrescribir su ubicación en la memoria después de que se libere?

Cualquier sugerencia sobre determinar si la ejecución del código es posible con este error, y cómo sucedería, también es bienvenida.

Gracias.

    
pregunta mds 06.05.2013 - 07:34
fuente

1 respuesta

1

Supondré que la pregunta tiene dos partes: "¿Se puede explotar? ¿Cómo puedo confirmar que esto es así?"

Probablemente lo sea. Probablemente estés en el camino correcto con el spray para pilas. ¿Has intentado deshabilitar ASLR? Eso ayudará a aclarar las cosas.

Aquí hay algunos comentarios de otra persona:

  

Este error no se puede replicar en las versiones más recientes. Pero probablemente podría realizar un spray de montón. Está informando que gdb está reportando una dirección diferente cada vez que esto es probablemente * debido a ASLR que debería girar que fuera y vuelva a encender para asegurarse. Puede pasar por el programa estableciendo algunos puntos de interrupción con gdb y determinando el contexto del bloqueo.

     

Pero idk porque no está probando la última versión en lugar de la versión de oldstable. Pero tengo enojado respeto por su vigor.

    
respondido por el daveloyall 25.07.2013 - 16:25
fuente

Lea otras preguntas en las etiquetas