La cadena de formato no controlada es un tipo de vulnerabilidad de inyección de código descubierta alrededor de 1989 que se puede utilizar en exploits de seguridad . [1] Originalmente considerados inofensivos, los exploits de cadena de formato se pueden utilizar para bloquear un programa o ejecutar código dañino. El problema surge del uso de la entrada de usuario no controlada como parámetro de cadena de formato en ciertas funciones de C que realizan formateo, como . Un usuario malintencionado puede utilizar los tokens de formato y , entre otros, para imprimir datos de la pila de llamadas o posiblemente otras ubicaciones en la memoria. También se pueden escribir datos arbitrarios en ubicaciones arbitrarias utilizando el token de formato, que ordena y funciones similares escribir la cantidad de bytes formateados en una dirección almacenada en la pila.printf()%s%x%nprintf()
Un exploit típico utiliza una combinación de estas técnicas para tomar el control del puntero de instrucción (IP) de un proceso, [2] por ejemplo, forzando a un programa a sobrescribir la dirección de una función de biblioteca o la dirección de retorno en la pila con un puntero a algún shellcode malicioso . Los parámetros de relleno para los especificadores de formato se utilizan para controlar la cantidad de bytes de salida y el %xtoken se utiliza para extraer bytes de la pila hasta que se alcanza el comienzo de la propia cadena de formato. El comienzo de la cadena de formato se crea para que contenga la dirección que el %ntoken de formato puede sobrescribir con la dirección del código malicioso que se ejecutará.
Se trata de una vulnerabilidad común, ya que antes se pensaba que los errores de formato eran inofensivos y generaban vulnerabilidades en muchas herramientas comunes. El proyecto CVE de MITRE enumera aproximadamente 500 programas vulnerables a junio de 2007, y un análisis de tendencias lo clasifica como el noveno tipo de vulnerabilidad más denunciado entre 2001 y 2006. [3]
Los errores de formato de cadena aparecen más comúnmente cuando un programador desea generar una cadena que contiene datos suministrados por el usuario (ya sea a un archivo, a un buffer o al usuario). El programador puede escribir por error printf(buffer)en lugar de printf("%s", buffer). La primera versión interpreta buffercomo una cadena de formato y analiza cualquier instrucción de formato que pueda contener. La segunda versión simplemente imprime una cadena en la pantalla, como lo pretendía el programador. Ambas versiones se comportan de manera idéntica en ausencia de especificadores de formato en la cadena, lo que hace que sea fácil que el desarrollador pase desapercibido el error.
Los errores de formato surgen porque las convenciones de paso de argumentos de C no son seguras en cuanto a tipos . En particular, el varargsmecanismo permite que las funciones acepten cualquier cantidad de argumentos (por ejemplo printf, ) "extrayendo" tantos argumentos de la pila de llamadas como deseen, confiando en que los primeros argumentos indiquen cuántos argumentos adicionales se deben extraer y de qué tipo.
Los errores de formato de cadena pueden ocurrir en otros lenguajes de programación además de C, como Perl, aunque aparecen con menos frecuencia y generalmente no pueden explotarse para ejecutar código elegido por el atacante. [4]
Los errores de formato se detectaron por primera vez en 1989 durante el trabajo de pruebas fuzz realizado en la Universidad de Wisconsin, que descubrió un "efecto de interacción" en el shell C (csh) entre su mecanismo de historial de comandos y una rutina de error que asumía una entrada de cadena segura. [5]
El uso de errores de cadenas de formato como vector de ataque fue descubierto en septiembre de 1999 por Tymm Twillman durante una auditoría de seguridad del demonio ProFTPD . [6] La auditoría descubrió un snprintfque pasaba directamente datos generados por el usuario sin una cadena de formato. Pruebas exhaustivas con argumentos artificiales para funciones de estilo printf mostraron que era posible su uso para la escalada de privilegios. Esto llevó a la primera publicación en septiembre de 1999 en la lista de correo Bugtraq sobre esta clase de vulnerabilidades, incluido un exploit básico. [6] Sin embargo, pasaron varios meses antes de que la comunidad de seguridad se diera cuenta de los peligros completos de las vulnerabilidades de cadenas de formato a medida que comenzaron a surgir exploits para otro software que usaba este método. Los primeros exploits que llevaron el problema a la conciencia común (al proporcionar acceso remoto a la raíz mediante la ejecución de código) fueron publicados simultáneamente en la lista Bugtraq en junio de 2000 por Przemysław Frasunek [7] y una persona que usaba el apodo tf8 . [8] Poco después, apareció una explicación publicada por una persona que usaba el sobrenombre de lamagra . [9] Pascal Bouchareine publicó "Format bugs" en la lista Bugtraq en julio de 2000. [10] El artículo seminal "Format String Attacks" [11] de Tim Newsham se publicó en septiembre de 2000 y otros artículos de explicación técnica detallada se publicaron en septiembre de 2001, como Exploiting Format String Vulnerabilities , del equipo Teso . [2]
Muchos compiladores pueden comprobar estáticamente cadenas de formato y generar advertencias para formatos peligrosos o sospechosos. En la Colección de compiladores GNU , los indicadores de compilación relevantes son, -Wall, -Wformat, -Wno-format-extra-args, -Wformat-security, -Wformat-nonliteral, y -Wformat=2. [12]
La mayoría de estos parámetros sólo son útiles para detectar cadenas de formato incorrectas que se conocen en tiempo de compilación. Si la cadena de formato puede provenir del usuario o de una fuente externa a la aplicación, la aplicación debe validar la cadena de formato antes de usarla. También se debe tener cuidado si la aplicación genera o selecciona cadenas de formato sobre la marcha. Si se utiliza la biblioteca GNU C, el -D_FORTIFY_SOURCE=2parámetro se puede utilizar para detectar ciertos tipos de ataques que ocurren en tiempo de ejecución. La -Wformat-nonliteralcomprobación es más estricta.
A diferencia de muchos otros problemas de seguridad, la causa raíz de las vulnerabilidades de las cadenas de formato es relativamente fácil de detectar en los ejecutables compilados en x86: en el caso de printflas funciones de la familia -, el uso adecuado implica un argumento independiente para la cadena de formato y los argumentos que se van a formatear. Los usos incorrectos de dichas funciones se pueden detectar simplemente contando la cantidad de argumentos que se pasan a la función; una "deficiencia de argumentos" [2] es entonces un fuerte indicador de que la función se utilizó incorrectamente.
Contar la cantidad de argumentos a menudo se hace fácil en x86 debido a una convención de llamada donde el llamador elimina los argumentos que se introdujeron en la pila agregándolos al puntero de pila después de la llamada, por lo que un simple examen de la corrección de la pila produce la cantidad de argumentos pasados a la printffunción -family. [2]
printfscanf