Compilando un exploit en un kernel diferente al objetivo (pero el mismo arco): ¿es insensible o arriesgado?

Question

Compilando un exploit en un kernel diferente al objetivo (pero el mismo arco): ¿es insensible o arriesgado?

#1 de forest (2 votos)

2

Estoy en una situación en la que he compilado aproximadamente 15 o más exploits para una máquina y cada uno ha fallado. Las fallas tenían que ver con el núcleo compilado con configuraciones altamente seguras, es decir, la función mmap se deshabilita o la función de seguimiento. Solo uno de los errores fue una falta de seguridad inexplicable. Ambas máquinas son x86, así que no es como si estuviera compilando de forma cruzada para un arco diferente.

¿Realmente vale la pena recompilar todas estas vulnerabilidades en una máquina virtual que coincida con el núcleo de la máquina de destino si ninguno de los errores (salvo el nebuloso Segfault) parece estar relacionado con problemas de compilación / compatibilidad?

exploit exploit-development

pregunta Info5ek 04.01.2017 - 08:38

fuente

1 respuesta

Lea otras preguntas en las etiquetas exploit exploit-development

autenticidad, confidencialidad e integridad - preguntas generales ¿Una transacción EMV autorizada fuera de línea usaría la validación de PIN fuera de línea?

score 2 · Answer 1

No importa en qué kernel compile un exploit.

Las fallas se debieron a que el kernel proporcionaba protecciones contra los métodos de explotación que utilizaste. Estas protecciones se realizan en tiempo de ejecución. El kernel no inserta de alguna manera el código para paralizar los exploits compilados debajo de él. La solución sería ejecutar el exploit en un kernel con estas características de seguridad eliminadas o inhabilitadas, no compilar en dicho kernel. No es necesario que tenga ASLR en ejecución (ni que sea compatible con su núcleo) para compilar un ejecutable independiente de la posición, por ejemplo.

El kernel en ejecución no cambia la salida del compilador de una manera que pueda romper un exploit. Lo único que importa es que lo está compilando con las mismas características (, al menos compatibles) del compilador, las bibliotecas (si están vinculadas estáticamente) y las optimizaciones. Si este es el caso, se puede compilar en cualquier lugar. Incluso podría compilar un exploit para una aplicación de Linux en Windows u OpenBSD, y viceversa.

Algunas cosas que debería tener en cuenta con respecto al entorno de su cadena de herramientas:

La compilación en un sistema con -march=native puede resultar en un ejecutable que no funciona correctamente o que no funciona en otro sistema. Evite las optimizaciones específicas del hardware.
El uso de características de, digamos, GCC 7.2.0 puede causar roturas si se compila en una máquina que solo tiene 6.4.0. Lo mismo se aplica a las regresiones que pueden romper una vulnerabilidad en un compilador más nuevo.
Si su destino tiene archivos de encabezado que son incompatibles con un exploit operativo por cualquier motivo, deberá incluir los archivos de encabezado correctos o compilarlos en un sistema que los tenga.
Los sistemas de compilación de algunas bibliotecas comprueban la versión del kernel en ejecución, y usan esto para decidir qué características incluir. Tenga en cuenta esto si también está compilando bibliotecas en este sistema.