IMChecker
1.0.0
Thu, IMCHECKER GROUP, contáctenos en [email protected]
Las bibliotecas ofrecen funcionalidad reutilizable a través de interfaces de programación de aplicaciones (API) con restricciones de uso, como condiciones de llamadas u órdenes. Las violaciones de restricción, es decir, los malos usuarios de la API, comúnmente conducen a errores y problemas de seguridad. Aunque los investigadores han desarrollado varios detectores API-Misuse en las últimas décadas, estudios recientes muestran que el mal uso de la API prevalece en los proyectos del mundo real. Los enfoques existentes sufren del problema de uso escaso (es decir, errores que rara vez ocurren) o informan falsas alarmas debido a una semántica inexacta. Para superar estas limitaciones, presentamos a ImChecker para detectar efectivamente los errores API-Misuse. La información clave detrás de ImChecker es una técnica de análisis estático dirigida por restricciones alimentada por un lenguaje específico de dominio (DSL) para especificar restricciones de uso de API. Al estudiar los errores API-Misuse del mundo real, proponemos IMSPEC DSL, que cubre la mayoría de los tipos de limitaciones de uso de API y permite una especificación simple pero precisa. Además, diseñamos e implementamos IMCHECKER para analizar automáticamente IMSPEC para verificar los objetivos y emplear un motor de análisis estático para identificar posibles mal uso de API y podar falsos positivos con una rica semántica. Hemos instanciado ImChecker para programas C y lo evaluamos en puntos de referencia ampliamente utilizados y programas en el mundo real a gran escala.
Actualmente, se han encontrado 75 errores previamente desconocidos y 61 se han confirmado y solucionado en Linux Kernel, OpenSSL y paquetes en Ubuntu 16.04. Estamos haciendo todo lo posible para aplicar IMCHECKER a más programas. Cargamos los detalles en evaluación_data/new_bugs
Nuestro manuscrito de investigación y manuscrito de herramientas están en proceso de revisión de ICSE'19. Los subiremos tan pronto como finalice el proceso de revisión. (Bueno, puede enviarnos un correo electrónico para acceder a ellos solo con fines académicos).
Nuestro video de demostración de herramientas está disponible en la versión en inglés: https://youtu.be/ygdxeyoevim versión china: https://www.youtube.com/watch?v=3zanegtwuto https://pan.baidu.com/s/1digq0r6wk5shhmlotk9kbg
Uso de nuestras herramientas en Tools/ReadMe.md
IMCHECKER todavía está en desarrollo y contiene muchos errores y listas de tareas. Cualquier error o solicitud de funciones, no dude en enviarnos un correo electrónico a [email protected] o abre problemas.
Para comprender mejor qué tipo de errores API-Misuse ocurren en proyectos CEAL C y cómo los desarrolladores los arreglan en la práctica, estudiamos manualmente dos años de historias de versiones de tres proyectos de código abierto y medio año de Linux-Kernel en 2017, como se muestra en la siguiente tabla. Estas historias se eligen debido al desarrollo en curso y porque con frecuencia se mencionan en diversos trabajos de detección de errores. En total, hemos estudiado aproximadamente 13.57m LOC y 51.1k compromisos.
| Proyecto | Loc | Período estudiado | Total de confirmación | Correcciones de errores | API mal uso |
|---|---|---|---|---|---|
| Rizo | 112.8k | 20160101-20171231 | 2613 | 135 | 38 |
| Gnutls | 35.8k | 20160101-20171231 | 2769 | 86 | 30 |
| Openssl | 454.2k | 20160101-20171231 | 6487 | 344 | 115 |
| Linux | 12.96m | 20170701-20171231 | 39295 | 995 | 362 |
| Total | 15.57m | Dos años | 51.1k | 1560 | 509 |
Para ayudar a los lectores a extraer el mensaje Commits, cambiar los archivos y los archivos de parches, abrimos la fuente de Source nuestra herramienta GitGrabber . También cargamos todos los compromisos relacionados con los errores API-Misuse en los sujetos estudiados para su uso posterior.
Los lectores pueden encontrarlos en la carpeta empírica_study. Cualquier problema en GitGrabber, ¡no dude en contactarnos!
Seleccionamos un punto de referencia ampliamente utilizado, es decir, Juliet Test Suite V1.3 y dos programas del mundo real en sus últimas versiones: Linux Kernel-4.18-RC4 lanzado el 2018-7-9 y OpenSSL-1-1-1-PRE8 lanzado el 2018-6-6-20 para evaluar nuestro enfoque. Evaluamos nuestro enfoque desde dos perspectivas.
También probamos estos casos en Apisan, una herramienta de detección de usos de API de desinfección a través de la verificación cruzada semántica y el clang-SA una herramienta de análisis estático de código abierto.
Subimos el Benchmark API-Misuse y los resultados originales en Evaluation_Data.
La principal motivación de IMCHECKER es detectar errores API-Misuse en programas del mundo real, a saber, para determinar si ImChecker puede encontrar errores previamente desconocidos. Por lo tanto, aplicamos IMCHECKER a las últimas versiones de dos programas de código abierto conocidos: Linux Kernel-4.18-RC4 y OpenSSL-1-1-1-PRE8, y paquetes en Ubuntu 16.04. Las API objetivo se seleccionan de las mal utilizadas del estudio empírico.
Hasta ahora, se han encontrado 56 errores previamente desconocidos y 36 han sido confirmados por los desarrolladores.
| Proyecto | Errores (respuesta de espera/confirmada/solucionada) |
|---|---|
| Openssl | 17 (0/5/12) |
| Linux | 30 (5/20/5) |
| DMA | 1 (0/0/1) |
| exim | 2 (0/0/2) |
| hexchat | 2 (1/1/0) |
| httping | 1 (1/1/0) |
| ipmitool | 1 (1/1/0) |
| Toolas de VM abiertas | 2 (0/0/2) |
| Irssi | 2 (1/1/0) |
| kidalive | 2 (0/0/2) |
| THC-IPV6 | 2 (0/0/2) |
| freeradius-server | 2 (0/0/2) |
| tráfico | 3 (3/0/0) |
| tinc | 2 (0/0/2) |
| sslplit | 2 (0/0/2) |
| rdesktop | 2 (2/0/0) |
| proxytunnel | 2 (2/0/0) |
| Total | 75 (16/29/32) |
Cargamos los detalles en evaluación_data/new_bugs
Se ha demostrado que las especificaciones de comportamiento que describen las limitaciones de uso de API son útiles para que los desarrolladores utilicen de manera efectiva las API, así como para hacer frente al problema de uso escaso al garantizar la validación de los usos de las API objetivo. Por ejemplo, Bodden presenta a Crysl para cerrar la brecha cognitiva entre los expertos en criptografía y los desarrolladores. Sin embargo, los lenguajes de especificación actual están diseñados para propiedades completas del programa, como BLAST, JML o son demasiado específicos para aplicarse a la detección genérica de uso de API, como SLIC. Introducimos un lenguaje liviano específico de dominio para las restricciones de uso de API llamado IMSPEC. IMSPEC se asegura simultáneamente que las API objetivo se validen, incluso con pocos usos, y guíen la detección de mal uso. Una instancia de IMSPEC es un patrón lleno de un conjunto de restricciones para usar correctamente la API, y cualquier violación dará como resultado un error API-Misuse.
Cargamos las instancias de IMSPEC en la carpeta ImpSEC, actualizaremos incrementalmente esta carpeta para obtener más API. Además, IMSPEC se puede usar para otro propósito, como generar casos de prueba, verificación, etc. Además, proporcionamos un escritor de GUI IMSPEC en las herramientas.
Actualmente, IMSPEC es creado por escritura manual. Sin embargo, nos aseguramos de que se pueda generar automáticamente a partir de técnicas de minería de especificaciones. Estamos haciendo todo lo posible para realizar experimentos e implementar analizadores para traducir los resultados de las herramientas mineras a IMSPEC, como Apex. Pero, estas herramientas no pueden resolver todas las limitaciones de uso. También nos gustaría invitar a los desarrolladores a ayudarnos a refinar las instancias IMSPEC generadas de acuerdo con el manual del usuario, como OpenSSL.
Un uso correcto de API tiene que satisfacer un conjunto de restricciones de uso, es decir, las violaciones de las limitaciones pueden dar lugar a errores API-Misuse. IMCHECKER detecta automáticamente estos errores en el código fuente utilizando las especificaciones de IMSPEC. Para procesar programas complejos del mundo real, los mecanismos subyacentes de Imchecker deben ser escalables mientras sacrifican la cantidad mínima de precisión. Elaboramos los detalles de diseño de ImChecker, incluida la ejecución simbólica poco limitada con técnicas de análisis estático para crear contexto de análisis, metodologías para detectar errores API-Misuse en el contexto de análisis y un método para filtrar falsos positivos utilizando información semántica y estadísticas de uso.
Utilizamos un ejemplo motivador para ilustrar el flujo de trabajo de Imchecker. Este es un error API-Misuse en OpenSSL informado en CVE-2015-0288. La verificación del código de error faltante de X509_get_pubkey() dio como resultado un error de deserencia de puntero nulo en la línea-4.
1 // Location: crypto/x509/x509_req.c: 70 2 X509_REQ *X509_to_X509_REQ(...){
3 ...
4 pktmp = X509 get pubkey ( x );
5 // missing error code check of pktmp
6 + if ( pktmp == NULL )
7 + goto err ;
8 i = X509_REQ_set_pubkey ( ret , pktmp ); 9 EVP_PKEY_free ( pktmp );
10 ...
11 }
12
13 // Location: /crypto/x509/x509_cmp.c: 390
14 int X509_chain_check_suiteb (...){
15 ...
16 // check error value in usage
17 pk = X509 get pubkey ( x );
18 rv = check_suite_b ( pk , -1 , & tflags );
19 ...
20 }
21 // Location: /crypto/x509/x509_cmp.c: 359
22 static int check_suite_b ( EVP_PKEY * pkey ,...){ 23 ...
24 // ensure pkey not NULL
25 if ( pkey && pkey -> type == EVP PKEY EC )
26 ... // usage of pkey
27 }Aquí está el flujo de trabajo de ImChecker:
IMCHECKER toma el código fuente y las restricciones de uso de API como entrada y genera informes de errores con ubicaciones y razones concretas como salida. Primero, las limitaciones de uso de API se escriben en un lenguaje liviano específico de dominio llamado IMSPEC; Por ejemplo, "el valor de retorno de x509_get_pubkey () debe verificarse con NULL" . Al emplear estas especificaciones, IMCHECKER valida directamente los usos de la API objetivo, lo que alivia el problema de uso escaso y guía el proceso de detección de errores. Luego, detectamos errores API-Misuse en tres fases. (1) En la fase-1, el contexto de análisis se construye construyendo el gráfico de flujo de control y creando trazas de ruta del programa para cada API objetivo definida en las especificaciones mediante el empleo de una ejecución simbólica poco limitada con análisis de punto a, rango y ruta sensible. En este ejemplo, se generan dos trazas, T1 y T2, como se muestra en el cuadro anterior trazas de la ruta del programa. De esta manera, ImChecker puede capturar con éxito el contexto de uso de X509_get_pubkey() , EVP_PKEY_free() y los intermedios. (2) En la fase 2, IMCHECKER emplea los rastros para detectar violaciones de las limitaciones como posibles errores. Forexample, se encuentran instancias de TwoApi-Misuse de X509_get_pubkey() para las verificaciones de código de error faltantes etiquetadas como posibles errores. (3) En la fase 3, ImChecker mejora la precisión de detección al aprovechar múltiples instancias de uso y la información semántica. Luego, el segundo mal uso se filtra para la verificación realizada en el X509_to_X509_REQ() en la línea-25.
El uso de nuestra herramienta se puede encontrar aquí: herramientas/readme.md
Mientras investigamos los informes de errores generados por ImChecker, encontramos varios errores interesantes y obtenemos experiencia útil en el proceso de informes de errores con desarrolladores de código abierto. Compartimos nuestra siguiente experiencia.
Los autores desean agradecer a los desarrolladores de Linux Kernel y OpenSSL para ayudarnos a refinar los informes IMSPEC y confirmar los informes de errores.
