gamozolabs/applepieUn hipervisor para fuzzing construido con WHVP y Bochs
¡Hola! ¡Bienvenido a applepie! Esta es una herramienta diseñada para fuzzing, introspección y encontrar errores. Es un hipervisor que utiliza la API de Windows Hypervisor Platform presente en versiones recientes de Windows (específicamente, fue desarrollado y probado en Windows 10 17763). Bochs se utiliza para proporcionar una introspección profunda y emulación de dispositivos.
La API de Windows Hypervisor Platform (WHVP) es un conjunto de API para acceder a las capacidades de hipervisor de Hyper-V. Esta API facilita la implementación de una máquina virtual completamente en el espacio de usuario, sin necesidad de controladores especiales ni permisos adicionales.
Este es un proyecto en rápido desarrollo. Probablemente twittearé cuando salgan nuevas funciones antes de que se documenten.
Me gusta tener objetos físicos para mis proyectos:
Esta es una herramienta diseñada para fuzzing e introspección durante la investigación en seguridad. Al usar un hipervisor, se pueden aplicar técnicas comunes de fuzzing a cualquier objetivo, ya sea kernel o espacio de usuario. Este entorno permite el fuzzing de sistemas completos sin necesidad del código fuente del objetivo. A nivel de hipervisor se puede recopilar cobertura de código y, si es necesario, se puede usar la emulación de Bochs para proporcionar introspección arbitraria en un entorno de emulación. Esta información de cobertura se puede utilizar para determinar la efectividad de los casos de fuzzing. Un caso de fuzzing que provocó un aumento en la cobertura se puede guardar por ser un caso interesante. Esta entrada se puede usar más tarde, mejorada con nuevas corrupciones.
El fuzzing con instantáneas es el uso principal de esta herramienta. Consiste en tomar una instantánea de un sistema en un estado determinado y guardarla. Luego, esta instantánea se puede cargar para el fuzzing, donde se inyecta un caso de fuzzing y se reanuda. Dado que la VM se puede reiniciar de manera muy económica, se puede reiniciar con frecuencia. Si Word tarda 5 segundos en iniciarse, pero puedes tomar una instantánea justo cuando lee tu archivo, puedes reducir el caso de fuzzing solo a lo que es relevante para una entrada. Esto permite un bucle de fuzzing muy ajustado sin necesidad de tener acceso al código fuente. Como las VM son sistemas completamente separados, se pueden ejecutar muchas en paralelo para escalar a todos los núcleos.
Actualmente, esta herramienta solo admite la recopilación de cobertura de código, la descarga dinámica de símbolos para Windows y el análisis de símbolos/módulos para objetivos Windows también. La adición de soporte para fuzzing será muy pronto.
Dado que ya he escrito casi todas las funciones aquí antes (cobertura, fuzzing, reinicios rápidos, etc.), espero que este proyecto se vuelva rápidamente utilizable para fuzzing, a menos que me distraiga :D
Apunto a finales de enero para cobertura (¡hecho!), comentarios, listados de módulos (¡hecho!), listas de procesos, reinicios rápidos y soporte de símbolos (¡hecho!). Eso lo convertiría en un fuzzer muy capaz.
El objetivo principal compatible es Windows 10 moderno. Los objetivos Windows tienen descarga de símbolos desde el almacén de símbolos. Esto permite una cobertura simbólica en objetivos Windows de forma inmediata. Sin embargo, el código está escrito de manera que se pueda agregar fácilmente iluminación para Linux.
Sin ninguna iluminación, cualquier sistema operativo que arranque aún puede ser fuzzeado y se puede recopilar cobertura básica.
Antes de informar problemas de soporte de SO, valide que el problema esté en el hipervisor/cambios en Bochs intentando arrancar su objetivo usando Bochs estándar preconstruido sin hipervisor. Bochs no se usa comúnmente y puede tener errores críticos incluso para cosas comunes como arrancar Linux. Especialmente con los rápidos cambios internos en los usos de CPUID/MSR con las mitigaciones de Spectre/Meltdown en los sistemas operativos.
Consulte la página de issues en Github para obtener una lista de problemas. Ya he sembrado algunos. Algunos de estos deben solucionarse rápidamente antes de que comience el desarrollo de fuzzing.
Para compilar esto necesitas algunas cosas:
Instale Visual Studio 2017 y asegúrese de que esté actualizado. Aquí estamos usando API, encabezados y bibliotecas de vanguardia.
Yo usaba la versión de cl.exe: Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27025.1 for x64
Y la versión del SDK 10.0.17763.0
Instale Rust a través de https://rustup.rs/. Yo usé rustc 1.32.0-nightly (b3af09205 2018-12-04)
Asegúrese de instalar el toolchain x86_64-pc-windows-msvc, ya que solo se admite 64 bits para este proyecto.
Asegúrese de que cargo esté en su PATH. Esto debería ser el valor predeterminado.
Vaya a https://www.python.org/ y asegúrese de que esté en su PATH para que se pueda invocar python.
Instale Cygwin de 64 bits (https://www.cygwin.com/setup-x86_64.exe) específicamente en C:\cygwin64. Al instalar Cygwin, asegúrese de instalar los paquetes autoconf y make.
Vaya a "Activar o desactivar las características de Windows" y marque la casilla junto a "Hyper-V" y "Windows Hypervisor Platform". Esto requiere, por supuesto, que su computadora tenga soporte para Hyper-V.
Esta guía de instalación fue verificada en lo siguiente:
Instalación limpia de Windows 10, Build 17763
rustc 1.33.0-nightly (8e2063d02 2019-01-07)
Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27025.1 for x64
Visual Studio Community 2017 version 15.9.4
applepie commit `f84c084feb487e2e7f31f9052a4ab0addd2c4cf9`
Python 3.7.2 x64
git version 2.20.1.windows.1
autoconf package)make package)git clone https://github.com/gamozolabs/applepiepython build.py
Este proceso de compilación inicial puede tomar unos 2 minutos; en una máquina moderna probablemente sean 20-30 segundos.
Simplemente ejecute python build.py desde el directorio raíz de este proyecto. Debería verificar la cordura del entorno y todo debería "funcionar sin problemas".
Ejecute python build.py clean para limpiar los binarios de Bochs y Rust.
Ejecute python build.py deepclean para eliminar completamente todos los binarios de Bochs y Rust, también elimina toda la configuración de Bochs. Use esto si reconfigura Bochs de alguna manera.
Lea sobre la configuración de Bochs para descubrir cómo configurar su entorno. Tenemos algunos requisitos, como sync=none, ips=1000000 y actualmente solo soporte de un solo procesador. Estos se aplican dentro del código para asegurarse de que no se dispare en el pie.
Use las configuraciones incluidas bochservisor_test\bochsrc.bxrc y bochservisor_test_real\bochsrc.bxrc como ejemplos. bochservisor_test_real es probablemente la configuración más actualizada que debe consultar como referencia.
Los objetivos Windows tienen iluminación de lista de módulos, lo que nos permite ver los listados de todos los módulos en el contexto en el que nos estamos ejecutando. Con esto podemos convertir las direcciones de instrucciones en módulo + desplazamiento. Este módulo + desplazamiento ayuda a mantener la información de cobertura entre casos de fuzzing donde cambia el estado de ASLR. También permite colorear el módulo en una herramienta como IDA para ver visualmente qué código se ha alcanzado.
Para objetivos Windows, los símbolos se descargarán dinámicamente del almacén de símbolos usando su _NT_SYMBOL_PATH y usando symchk. Sin symchk en el PATH fallará silenciosamente. Con símbolos, se puede guardar una versión legible de la cobertura para su visualización. Además, con símbolos privados, la cobertura se puede convertir a fuente:línea para que el código fuente pueda colorearse.
Bueno, realmente no hay pruebas, pero hay bochservisor_test, que es un sistema operativo diminuto que solo verifica que todo arranque con el hipervisor.
Luego está bochservisor_test_real, que es una configuración que uso para cosas como Windows/Linux. Es la que probablemente se actualizará con más frecuencia.
Este código introduce una pequeña cantidad de código en Bochs para permitir el acceso modular al contexto de la CPU, la memoria física del invitado con su respaldo, y el avance del estado tanto de dispositivos como de la CPU.
El código principal que debe mirar está en lib.rs en el proyecto Rust bochservisor.
En el bucle principal de la CPU de Bochs, en su lugar usamos LoadLibrary() para cargar la DLL bochservisor. Esta DLL exporta una rutina que es el bucle de CPU de Rust que se invocará.
Bochs pasará una estructura a esta rutina bochs_cpu_loop que contendrá punteros a funciones para obtener información de Bochs y para avanzar el estado del dispositivo y la CPU en él.
Cuando ocurre MMIO o E/S, el hipervisor sale con una falla de memoria o una falla de instrucción de E/S. Si bien WHVP proporciona una API de emulación, es realmente deficiente e insuficiente.
En lugar de eso, usamos Bochs, que ya está ahí, y avanzamos unas pocas instrucciones. Al mantener el estado de la CPU del hipervisor sincronizado con Bochs, podemos cambiar dinámicamente entre hipervisor y emulación en cualquier momento (o al menos deberíamos poder hacerlo).
Esto significa que el estado completo del hipervisor siempre está sincronizado con Bochs, por lo que cosas como las instantáneas de Bochs deberían funcionar con normalidad y podrían iniciarse sin el hipervisor (excepto quizás algún estado de CPUID que deba almacenarse en la información de la instantánea).
Cuando ocurre MMIO o E/S, ejecutamos un cierto número de instrucciones bajo emulación en lugar de emular solo una. Debido a los costos de API de entrar y salir del hipervisor, y la probabilidad de que ocurran operaciones MMIO similares cerca unas de otras, avanzamos unas pocas instrucciones. Esto nos permite reducir la sobrecarga de la API y reduce la frecuencia de VMEXIT. Este es un número ajustable, pero lo que está en el código probablemente está ahí por una razón.
Manejamos las interrupciones de una manera muy interesante. En lugar de programar interrupciones para que se entreguen al hipervisor, manejamos todas las interrupciones en la emulación de Bochs. Por supuesto, cosas como las excepciones que ocurren completamente dentro del hipervisor no son manejadas por Bochs.
Esto también nos brinda funciones que WHVP no soporta, como SMIs (para SMM). El BIOS de Bochs usa SMM por defecto y sin soporte SMI, se necesita construir un BIOS personalizado. Hice esto en mi primera iteración... no lo recomiendo.
Este proyecto está diseñado para fuzzing, sin embargo, es tan nuevo (solo tiene unos pocos días) que no tiene ninguna de estas características.
Algunas de las primeras cosas que vendrán serán:
Podríamos tener la parte de dispositivos de Bochs ejecutándose en un hilo en un bucle en tiempo real, y otro hilo ejecutando el hipervisor. Los eventos asincrónicos se comunicarían a través de IPC y permitirían que los dispositivos se actualicen mientras se ejecuta en el invitado.
Actualmente, todo ocurre en un solo hilo, lo que significa que el hipervisor debe salir en un intervalo para asegurarse de que podamos avanzar los dispositivos. Es como si hubiéramos escrito nuestro propio planificador.
Esto podría ser un poco más rápido, pero también aumenta la complejidad y agrega el potencial de problemas de concurrencia. Es difícil decir si esto ocurrirá alguna vez.
No estoy seguro de qué método usaré para recopilar cobertura de código, pero habrá al menos algunas opciones. Desde precisas hasta rápidas, etc. Todos estos mecanismos de cobertura serán a nivel de sistema y no requerirán fuente ni símbolos de los objetivos.
Análisis de estructuras del sistema operativo para obtener información primitiva como listados de procesos, listas de módulos, etc. Esto se usaría luego para consultar PDBs y obtener información de símbolos.
Reportar fallos de alguna manera significativa. Idealmente, los minivolcados serían agradables, ya que podrían cargarse y procesarse en WinDbg. Esto podría ser bastante fácil, ya que los DMP son solo memoria física y contexto del procesador, que ya tenemos.
Tengo algunas técnicas divertidas para determinar la causa raíz de errores que han tenido éxito históricamente. Planeo traerlas aquí.
Al rastrear páginas sucias y restaurar solo las cosas modificadas, deberíamos poder reiniciar las VM muy rápidamente. Esto nos da la capacidad de fuzzing a velocidades máximas en todos los núcleos de un objetivo de sistema. Esto es similar a lo que hice en falkervisor, por lo que ya está pensado y diseñado. Solo necesita ser portado aquí.
Fuzzing extremadamente rápido que cancela la ejecución cuando ocurre MMIO o E/S. Esto permite que todo el tiempo de CPU se gaste en el hipervisor y sin tiempo de emulación. Tiene la desventaja de no admitir cosas como E/S de disco durante un caso de fuzzing, pero es agradable.
Algunos de los conceptos centrales de este proyecto son modificaciones mínimas absolutas a Bochs. Esto nos permite mantener actualizada la parte de Bochs de este repositorio.
El objetivo también es mover la mayor cantidad de código posible a Rust y DLLs para hacer el sistema mucho más modular y seguro. Esto espera reducir las posibilidades de cometer errores de corrupción tontos en el propio hipervisor, lo que causaría resultados de fuzzing inválidos.
Actualmente, el hipervisor es una DLL y se puede intercambiar sin cambios en Bochs (a menos que la API FFI cambie).
Los cambios adicionales en Bochs en sí deben documentarse claramente, y pronto crearé un documento para eso para rastrear los cambios en Bochs que deben ser portados y reevaluados con las actualizaciones de Bochs.