Revelando el código Abyss: invertir LLMS para exponer vórtices de vulnerabilidad en programas generados por IA

Tabla de enlaces

Resumen e I. Introducción

II. Trabajo relacionado

Iii. Antecedentes técnicos

IV. Descubrimiento de vulnerabilidad de seguridad sistemática de modelos de generación de código

V. Experimentos

VI. Discusión

Vii. Conclusión, reconocimientos y referencias

Apéndice

A. Detalles de modelos de idioma de código

B. Encontrar vulnerabilidades de seguridad en Copilot GitHub

C. Otras líneas de base que usan chatgpt

D. Efecto de diferentes ejemplos de pocos disparos

E. Efectividad en la generación de vulnerabilidades específicas para los códigos C

F. Resultados de vulnerabilidad de seguridad después de la deduplicación del código difuso

G. Resultados detallados de la transferibilidad de las indicaciones no geniales generadas

H. Detalles de la generación del conjunto de datos de indicaciones no seguras

I. Resultados detallados de la evaluación de CODELMS utilizando un conjunto de datos no seguro

J. Efecto de la temperatura de muestreo

Ok. Efectividad del esquema de inversión del modelo en la reconstrucción de los códigos vulnerables

L. Ejemplos cualitativos generados por Codegen y ChatGPT

M. Ejemplos cualitativos generados por GitHub Copilot

A continuación, presentamos brevemente el trabajo existente en modelos de idiomas grandes y discutimos cómo este trabajo se relaciona con nuestro enfoque.

A. Modelos de idiomas grandes y indicaciones

Los modelos de idiomas grandes han avanzado el campo de procesamiento del lenguaje pure en varias tareas, incluida la respuesta a las preguntas, la traducción y la comprensión de la lectura. [1], [17]. Estos hitos se lograron escalando el tamaño del modelo de cientos de millones [18] a cientos de miles de millones [1]Funciones objetivas auto-supervisadas, refuerzo de refuerzo de la retroalimentación humana [19]y enormes corpus de datos de texto. Muchos de estos modelos están capacitados por grandes empresas y luego lanzados como modelos previamente capacitados. Brown et al. [1] Demuestre que estos modelos pueden usarse para abordar una variedad de tareas proporcionando solo unos pocos ejemplos como entrada, sin ningún cambio en los parámetros de los modelos. El usuario last puede usar una plantilla como un mensaje de pocos disparos para guiar los modelos para generar la salida deseada para una tarea específica. En este trabajo, mostramos cómo se puede utilizar un enfoque de solicitación de pocos disparos para generar código con vulnerabilidades específicas al aproximar la inversión de los modelos de generación de código de caja negra.

B. Modelos de idiomas grandes de códigos fuente

Existe un creciente interés en usar modelos de lenguaje grandes para la comprensión del código fuente y las tareas de generación. [7], [5], [20]. Feng et al. [21] y Guo et al. [22] Proponga modelos solo del codificador con una variante de funciones objetivas. Estos modelos [21], [22] Centrarse principalmente en la clasificación de código, la recuperación de código y la reparación del programa. Ahmad et al. [23] y Wang et al. [20] Emplee la arquitectura del codificador del codificador para abordar el código a código y las tareas de generación de código a texto, incluida la traducción del programa, la reparación del programa y el resumen de código. Recientemente, los modelos decoderonamente han mostrado resultados prometedores en la generación de programas de izquierda a derecha [5], [4], [6], [12]. Estos modelos se pueden aplicar a tareas de generación de programas de disparo cero y pocos disparos [5], [6], [24], [12]incluida la finalización del código, el relleno de código y las tareas de texto para código. Se han evaluado principalmente modelos de código de lenguaje en función de la corrección funcional de los códigos generados sin considerar posibles problemas de vulnerabilidad de seguridad (ver Sección II-C para una discusión). En este trabajo, proponemos un enfoque para encontrar automáticamente vulnerabilidades de seguridad específicas que pueden generar estos modelos a través de la aproximación de la inversión de los modelos de caja negra objetivo a través de pocas indicaciones.

C. Problemas de vulnerabilidad de seguridad de los modelos de generación de códigos

Los modelos de generación de códigos de idioma grandes se han entrenado previamente utilizando grandes corpus de datos de código de código abierto [7], [5], [25]. Estos códigos de código abierto pueden contener una variedad de diferentes problemas de vulnerabilidad de seguridad, incluidas las violaciones de seguridad de la memoria. [26]API y algoritmos en desuso (por ejemplo, algoritmo de hash MD5 [27], [15]) o inyección SQL y secuencias de comandos de sitios cruzados [28], [15] vulnerabilidades. Los modelos de idiomas grandes pueden aprender estos patrones de seguridad y potencialmente generar códigos vulnerables dadas las entradas de los usuarios. Recientemente, Pearce et al. [15] y Siddiq y Santos [28] Muestre que los códigos generados utilizando modelos de generación de código pueden contener varios problemas de seguridad.

Pearce et al. [15] Use un conjunto de escenarios diseñados manualmente para investigar posibles problemas de vulnerabilidad de seguridad del copiloto de GitHub [9]. Estos escenarios se seleccionan mediante el uso de un conjunto limitado de códigos vulnerables. Cada escenario contiene las primeras líneas de los códigos potencialmente vulnerables, y los modelos se consultan para completar los escenarios. Estos escenarios fueron diseñados en base a la enumeración de debilidad común de Miter (CWE) [29]. Pearce et al. [15] Evalúe las vulnerabilidades de los códigos generados empleando la herramienta de análisis estático de código GitHub. Estudios previos [15], [30], [28] Examinaron problemas de seguridad en los modelos de generación de códigos, pero se basaron en un conjunto limitado de escenarios diseñados manualmente, lo que podría resultar en la falta de códigos potenciales de generación con ciertos tipos de vulnerabilidad. En contraste, nuestro trabajo propone un enfoque sistemático para encontrar vulnerabilidades de seguridad al generar automáticamente varios escenarios a escala. Esto nos permite crear un conjunto diverso de indicaciones no seguras para evaluar y comparar los modelos con respecto a la generación de código con problemas de seguridad.

D. inversión de modelo y extracción de datos

Se ha aplicado una inversión de modelo profundo a la explicación del modelo [31]destilación modelo [32]y más comúnmente para reconstruir datos de capacitación privada [33], [34], [35], [36]. El objetivo common en la inversión del modelo es reconstruir una vista representativa de los datos de entrada basados en las salidas de los modelos [34]. Recientemente, Carlini et al. [37] demostró que es posible extraer datos memorizados de modelos de idiomas grandes. Estos datos incluyen información private como correo electrónico, URL y números de teléfono. En este trabajo, utilizamos pocos indicios de disparo para aproximar una inversión de los modelos de código de caja negra específicas. Aquí, nuestro objetivo es emplear la inversión aproximada de los modelos para encontrar automáticamente los escenarios (indicaciones) que llevan a los modelos a generar códigos con un tipo específico de vulnerabilidad.

Iii. Antecedentes técnicos

La detección de errores de software program antes de la implementación puede evitar daños potenciales y costos imprevisibles. Sin embargo, encontrar automáticamente los errores críticos de seguridad en el código es una tarea desafiante en la práctica. Esto también incluye código generado por el modelo, especialmente dada la naturaleza de la caja negra y la complejidad de tales modelos. A continuación, elaboramos sobre los métodos de análisis recientes y los esquemas de clasificación para las vulnerabilidades de código.

A. Evaluación de problemas de seguridad

Se pueden utilizar varios métodos de prueba de seguridad para encontrar vulnerabilidades de software program para evitar errores durante el tiempo de ejecución de un sistema implementado [38], [39], [40]. Para lograr este objetivo, estos métodos intentan detectar diferentes tipos de errores de programación, un estilo de codificación deficiente, funcionalidades desactivadas o posibles violaciones de seguridad de la memoria (por ejemplo, acceso no autorizado a memoria insegura que puede explotarse después de la despliegue u obsoletar esquemas criptográficos que están inseguros que están inseguros [41], [42], [26]). En términos generales, los métodos actuales para la evaluación de seguridad del software program pueden ser

dividido en dos categorías: estática [38], [43] y análisis dinámico [44], [45]. Mientras que el análisis estático evalúa el código de un programa determinado para encontrar vulnerabilidades potenciales, este último enfoque ejecuta los códigos. Por ejemplo, las pruebas de fuzz (fuzzing) genera ejecuciones de programas aleatorias para activar los errores.

Para el propósito de nuestro trabajo, elegimos utilizar el análisis estático para evaluar el código generado, ya que nos permite clasificar el tipo de vulnerabilidades detectadas. Específicamente, usamos CodeQL, uno de los motores de análisis estático gratuito de mejor rendimiento lanzados por GitHub [46]. Para analizar el código generado por el modelo de idioma, consultamos el código a través de CodeQL para encontrar vulnerabilidades de seguridad en el código. Utilizamos la salida de clasificación CWE de CodeQL para clasificar el tipo de vulnerabilidad que se ha encontrado durante nuestra evaluación y para definir un conjunto de vulnerabilidades que investigamos a lo largo de este trabajo.

B. Clasificación de debilidades de seguridad

Enumeraciones de debilidades comunes (CWES) es una lista de defectos típicos en software program y {hardware} proporcionado por Miter [29]a menudo con ejemplos de vulnerabilidad específicos. En whole, más de 400 tipos diferentes de CWE se definen y clasifican en diferentes clases y variantes, por ejemplo, errores de corrupción de memoria. El Listado 1 muestra un ejemplo de CWE-502 (deserialización de datos no confiables) en Python. En este ejemplo de [29]la biblioteca de Pickle se utiliza para deserializar datos: el código analiza los datos e intenta autenticar a un usuario basado en validar un token, pero sin verificar los datos entrantes. Un atacante potencial puede construir un pepinillo, que genera nuevos procesos, y dado que Pickle permite que los objetos definan el proceso de cómo deben ser nocados, el atacante puede dirigir el proceso de desbloqueo para llamar al subproceso módulo y ejecutar /bin /sh.

Para nuestro trabajo, nos centramos en el análisis de trece CWE representativos que se pueden detectar a través de herramientas de análisis estático para demostrar que podemos generar sistemáticamente un código weak y sus indicaciones de entrada. Decidimos no usar Fuzzing para la detección de vulnerabilidades debido al costo computacional potencialmente alto y el esfuerzo handbook impuesto por el análisis de causa raíz. Algunas CWE representan meros olores de código o requieren considerar el proceso de desarrollo y despliegue y, por lo tanto, están fuera de alcance para este trabajo. Los trece CWE analizados, incluida una breve descripción, se enumeran en la Tabla I. de los trece CWE listados, as soon as son de la lista de las 25 principales vulnerabilidades más importantes. La descripción es definida por Mitre [29].