pate
1.0.0
Este repositorio implementa una herramienta para verificar que los parches se aseguran hasta la equivalencia de rastreo (PATE).
El objetivo es demostrar que los parches de seguridad aplicados a los binarios solo eliminan los malos comportamientos, o los caracterizan con precisión para el desarrollador del parche. El verificador admite binarios PowerPC y AARCH32 (que actualmente requiere binarios de elfos vinculados estáticamente).
La forma más rápida de comenzar es construir la imagen de Docker y usar la herramienta a través de Docker. Para obtener instrucciones de compilación más profundas, consulte la sección de desarrollo, a continuación.
Primero, cree la imagen Docker con el comando:
Docker Build -Platform Linux/AMD64. -Tecidora
A continuación, ejecute el verificador en un ejemplo:
Docker ejecutando ---rm -it --platform Linux/amd64 -v "$ (pwd)"/tests/integración/paquete/exe:/target pate --original /target/packet.exe --patched /target/packet.patched.exe -s parse_packet
El verificador acepta los siguientes argumentos de línea de comando:
-H,-Ayuda a mostrar este texto de ayuda
-O,-Original exe Original Binary
-P,-binario parcheado de exe parcheado
-B,-Información de bloque de nombre de archivo blockinfo que relaciona binarios
-S,-Iniciente Análisis de inicio arg de arg desde la función con este símbolo
-d,-Nodiscovery no descubra dinámicamente pares de funciones basados en
llamadas.
--solver arg que el solucionador SMT se utilizará para resolver la verificación
condiciones. Uno de CVC4, Yices o Z3
(predeterminado: yices)
-goal timeout arg el tiempo de espera para verificar los objetivos individuales en segundos
(predeterminado: 300)
-Tiempo de tiempo heurístico arg el tiempo de espera para verificar los objetivos heurísticos en segundos
(predeterminado: 10)
-Original-Anvill intenta arg
Analizar una especificación de Anvill para el descubrimiento de código
pistas
-Patched-Anvill intenta arg
Analizar una especificación de Anvill para el descubrimiento de código
pistas
-arg de intensiones-introbabilísticos
Analizar un archivo JSON que contiene función probabilística
sugerencias de nombre/dirección
-argumento de introducción-probabilística
Analizar un archivo JSON que contiene función probabilística
sugerencias de nombre/dirección
-Original-CSV-Funcion intenta arg
Analizar un archivo CSV que contiene nombre/dirección de la función
pistas
-Patched-CSV-Function intenta arg
Analizar un archivo CSV que contiene nombre/dirección de la función
pistas
-Original-BSI-intenta arg parse un archivo json que contiene nombre/dirección de la función
pistas
-Patched-BSI-Hints Arg Parse Un archivo JSON que contiene nombre/dirección de la función
pistas
--No-Dwarf-Hints no extraen metadatos de la información enana en
los binarios
-V,-verbosidad arg la verbosidad de la salida de registro (predeterminado: información)
--Save-Macaw-CFGS Dir Save Macaw CFGS en el directorio proporcionado
-Archivo de archivo de interacción-solucionador
Guardar interacciones con el solucionador SMT durante el simbólico
Ejecución a este archivo
-Archivo a prueba de json-json
Un archivo para guardar resultados de prueba interesantes en JSON
formato
-LOG-FILE ARCHIVO Un archivo para guardar los registros de depuración para
-E,-Modo de manejo de errores de verificador de errorgrogue Arg
(predeterminado: throwonanyfailure)
-r,-modo de manejo de falla de rescopación de rescopemode arg
(predeterminado: throwoneqrescopefailure)
-Ship-Skip-Unnamed-Functions Skip Analysis de funciones sin símbolos
--Skip-Divergent-Control-Flow
<Spreced>
-Arget-o-o-ovhiv-Regs Arg calcula una condición de equivalencia suficiente para
establecer la igualdad en los registros dados después del
Toplevel EntryPoint Devuelve. <Spreced>
--Entore-segments arg segmentos de omisión (0-índice) al cargar elfo
--json-toplevel Run toplevel en modo JSON-Output (modo interactivo
solo)
-Segmentos de solo segmentos de lectura arg. Segmentos de marca como solo lectura (0-indexado) al cargar
DUENDE
--script FileName Save Macaw CFGS en el directorio proporcionado
--sassume-stack-scope agregue suposiciones adicionales sobre el alcance del marco de la pila
Durante las llamadas de función (inseguro)
--Ingore-Warnings Arg No plantee ninguno de los tipos de advertencia dados
-Always-Classify-Return siempre resuelve las fallas del clasificador asumiendo
devuelve la función, si es posible.
La sección de inicio rápido describió un comando para ejecutar el verificador en un caso de prueba utilizando el contenedor Docker. Esta sección cubrirá algunos comandos útiles para otros escenarios.
Si tiene un archivo tar de una imagen Docker del verificador, puede instalarlo usando el comando:
Docker Load -i /path/to/pate.tar
Para ejecutar el verificador a través de Docker después de esto:
Docker Run - -RM -IT --Platform Linux/AMD64 Pate --help
Para utilizar el verificador con Docker, es útil asignar un directorio en su sistema de archivos local en el contenedor Docker para poder guardar archivos de salida. Suponiendo que sus binarios originales y parchados sean original.exe y patched.exe , respectivamente:
mkdir verifierdata
CP original.exe Patched.exe Verifierdata/
Docker Run - -RM -IT --Platform Linux/AMD64
-v `pwd`/verifierdata`:/verifierdata Pate
--original /verifierdata/original.exe
--patched /verifierdata/patched.exe
--proof-summary-json /verifierdata/report.json
--log-file /verifierdata/pate.log
--save-macaw-cfgs /verifierdata /cfgs
Este comando ejecutará el verificador en los dos binarios y lo dejará en un bucle de lectura de impresión, donde puede explorar interactivamente la salida del verificador.
Por defecto, el verificador comienza a verificar desde el punto de entrada formal del programa. Esto a menudo no es muy útil (y puede ser problemático para los binarios complejos con un gran _start que causa problemas para nuestro descubrimiento de código). Además, para los cambios con un alcance de impacto conocido (o al menos esperado), analizar solo las funciones afectadas es significativamente más rápido. En su lugar, especificar un punto de entrada de análisis, pasar la opción -s <function_symbol> iniciará el análisis de la función correspondiente al símbolo dado. Tenga en cuenta que esto requiere que se proporcionen símbolos de función para los binarios (ya sea como símbolos de depuración incrustados o por separado en uno de los formatos de pista).
Si bien no es sólido, a veces es útil tratar una llamada de función como una OPS NO-OP. Por ejemplo, ignorar las grandes funciones que no han cambiado y es poco probable que tengan un efecto sobre la corrección (por ejemplo, grandes funciones criptográficas de bibliotecas confiables) puede mejorar significativamente el rendimiento. Para usar esta función, pase un archivo de configuración al verificador utilizando la opción --blockinfo , asegurando que el archivo de configuración incluya las siguientes directivas:
Ignorar-organizaciones originales = [<<riring>, ...] Ignore-Patched-Functions = [<<riring>, ...]
donde cada una de las listas es una lista de direcciones de funciones para ignorar. Si bien las dos listas se especifican por separado, casi seguramente deberían estar "alineados" entre los dos binarios (es decir, ignorar una función en el binario original probablemente significa que la función correspondiente en el binario parcheado también debe ignorarse).
El verificador se beneficia de los metadatos enanos de dos maneras:
Para inyectar metadatos enanos en binarios sin él (por ejemplo, binarios despojados), recomendamos usar la herramienta enana-escritor. Como ejemplo del uso de dwarf-writer a través de su imagen Docker suponiendo la existencia de un objetivo ( target-binary.exe ) y metadatos en el formato Anvill JSON ( target-binary.exe.json ):
Docker Load -I Dwarf-Writer-Docker.tar
mkdir dwarfwriterdata
CP Target-Binary.exe Target-Binary.exe.json DwarfwriterData/
Docker Run - -RM -IT -V `PWD`/DWARFWriterData:/DwarfWriterData Dwarf -Writer
--anvill /dwarfwriterdata/target-binary.exe.json
/Dwarfwriterdata/target-binary.exe
/Dwarfwriterdata/target-binary-dwarf.exe
Esto producirá una versión del binario anotado con metadatos enanos en DwarfWriterData/target-binary-dwarf.exe .
Si tiene la herramienta llvm-dwarfdump , puede usarla para inspeccionar los metadatos enanos generados. El verificador pate aprovechará automáticamente los sugerencias de metadatos enanos a menos que se le indique que los ignore.
El verificador toma dos binarios como entrada: un binario original y un binario parcheado. La suposición es que se ha aplicado algún parche orientado a la seguridad al binario original que conserva en gran medida su comportamiento, pero puede arreglar algunos comportamientos indeseables. El verificador luego intenta demostrar que los dos binarios exhiben el mismo comportamiento observable; Si no puede, produce un resumen diferencial que describe las condiciones bajo las cuales el binario parcheado exhibe un comportamiento diferente del original. Esto permite a los desarrolladores de parches comprender el impacto de sus parches en la semántica del programa y evaluar si el impacto está restringido a las rutas de ejecución que pretendían.
El verificador no requiere una especificación proporcionada manualmente de los usuarios; En cambio, trata el programa original como la especificación de comportamiento deseada. Este arreglo hace del paté un verificador relacional , ya que relata el binario parcheado con el original. El verificador se basa en una serie de bibliotecas existentes para el descubrimiento de código binario y la ejecución simbólica de programas (incluidos los programas de código de máquina). Aproximadamente, el verificador funciona por:
La herramienta Pate está escrita en Haskell y requiere el compilador GHC (probamos con 9.6) y la herramienta de compilación de Cabal para compilar. El edificio desde la fuente se puede lograr por:
Git clone [email protected]: Galoisinc/Pate.git paté actualización de submódulo de git --init cp cabal.project.dist cabal.project Cabal Configurar PKG: Pate ./pate.sh --help
El verificador requiere que un solucionador SMT esté disponible en PATH . El valor predeterminado es yices : z3 y cvc4 también pueden funcionar, pero no se prueban regularmente con Pate.
Este material se basa en el trabajo respaldado por la Agencia de Proyectos de Investigación Avanzada de Defensa (DARPA) y el Centro de Guerra de Información Naval Pacific (NIWC Pacific) bajo el número de contrato N66001-20-C-4027. Cualquier opinión, hallazgos y conclusiones o recomendaciones expresadas en este material son las del autor (s) y no reflejan necesariamente las opiniones del Pacífico DARPA & NIWC.
