Cadena de formato no controlada

La cadena de formato no controlada es un tipo de vulnerabilidad de inyección de código descubierta alrededor de 1989 que puede usarse en exploits de seguridad . ^{[ 1 ]} Originalmente considerada inofensiva, la explotación de cadenas de formato puede usarse para bloquear un programa o para ejecutar código dañino. El problema surge del uso de entrada de usuario no verificada como parámetro de cadena de formato en ciertas funciones de C que realizan formato, como . Un usuario malicioso puede usar 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 usando el token de formato, que comandos y funciones similares para escribir el número 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 de los especificadores de formato se utilizan para controlar el número de bytes de salida y el %xtoken se utiliza para extraer bytes de la pila hasta que se alcanza el inicio de la propia cadena de formato. El inicio de la cadena de formato se diseña para contener la dirección que el %ntoken de formato puede sobrescribir con la dirección del código malicioso a ejecutar.

Esta es una vulnerabilidad común porque los errores de formato se consideraban inofensivos y, sin embargo, 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 la sitúa como el noveno tipo de vulnerabilidad más reportado entre 2001 y 2006. ^{[ 3 ]}

Los errores de formato de cadena suelen aparecer cuando un programador desea mostrar una cadena con datos proporcionados por el usuario (ya sea en un archivo, en un búfer o directamente al usuario). El programador puede escribir erróneamente printf(buffer)en lugar de printf("%s", buffer). La primera versión interpreta buffercomo una cadena de formato y analiza las instrucciones de formato que pueda contener. La segunda versión simplemente imprime la cadena en pantalla, tal como lo pretendía el programador. Ambas versiones se comportan de forma idéntica en ausencia de especificadores de formato en la cadena, lo que facilita que el error pase desapercibido para el desarrollador.

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 número 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é tipos.

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 ser explotados para ejecutar código elegido por el atacante. ^{[ 4 ]}

Los errores de formato se detectaron por primera vez en 1989 mediante el trabajo de pruebas de fuzzing 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 cadena 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 extensas con argumentos artificiales a funciones de estilo printf mostraron que era posible usar esto 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, incluyendo un exploit básico. ^{[ 6 ]} Sin embargo, pasaron varios meses antes de que la comunidad de seguridad tomara conciencia de los peligros totales de las vulnerabilidades de cadena de formato a medida que comenzaron a aparecer exploits para otro software que usaban este método. Los primeros exploits que llevaron el problema a la conciencia pública (al proporcionar acceso root remoto a través de 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, una persona con el apodo lamagra publicó una explicación . ^{[ 9 ]} Pascal Bouchareine publicó "Errores de formato" en la lista Bugtraq en julio de 2000. ^{[ 10 ]} El artículo fundamental "Ataques a cadenas de formato" ^{[ 11 ]} de Tim Newsham se publicó en septiembre de 2000 y otros artículos con explicaciones técnicas detalladas se publicaron en septiembre de 2001, como Explotación de vulnerabilidades de cadenas de formato , del equipo Teso . ^{[ 2 ]}

En lenguajes modernos como Java (con String.format()), C# (con String.Format()o sus cadenas interpoladas ) y C++ (con std::format()), este tipo de ataques de formato de cadena ya no es posible, pero aún pueden existir otras vulnerabilidades de formato de cadena, como la que permitió Log4Shell .

Muchos compiladores pueden verificar estáticamente las cadenas de formato y generar advertencias para formatos peligrosos o sospechosos. En la Colección de Compiladores GNU , las banderas de compilador relevantes son , -Wall, -Wformat, -Wno-format-extra-args, -Wformat-security, -Wformat-nonliteral, y -Wformat=2. ^{[ 12 ]}

La mayoría de estas opciones solo son útiles para detectar cadenas de formato incorrectas conocidas en tiempo de compilación. Si la cadena de formato puede provenir del usuario o de una fuente externa a la aplicación, esta debe validarla 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 puede usarse para detectar ciertos tipos de ataques que ocurren en tiempo de ejecución. La -Wformat-nonliteralverificació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 para x86: para printflas funciones de la familia, el uso correcto implica un argumento separado para la cadena de formato y los argumentos que se van a formatear. Los usos erróneos de dichas funciones se pueden detectar simplemente contando el número 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 ha utilizado incorrectamente.

• La programación entre aplicaciones explota un tipo similar de error de programación.
• Secuencias de comandos entre sitios
• printf
• scanf
• syslog
• Validación de entrada incorrecta
• La inyección SQL es un ataque similar que tiene éxito cuando la entrada no está filtrada.

• Cowan, Crispin (agosto de 2001). FormatGuard: protección automática contra vulnerabilidades en cadenas de formato printf (PDF) . Actas del 10.º Simposio de Seguridad de USENIX.
• Cowan, Crispin (enero-febrero de 2003), Seguridad de software para sistemas de código abierto , IEEE Security & Privacy, IEEE Computer Society
• Klein, Tobías (2004). Desbordamientos de búfer y Format-String-Schwachstellen - Funktionsweisen, Exploits und Gegenmaßnahmen (en alemán) (1  ed.). dpunkt.verlag . ISBN 3-89864-192-9.(vii+663 páginas)
• Seacord, Robert C. (septiembre de 2005). Codificación segura en C y C++ . Addison Wesley . ISBN 0-321-33572-4.

• Introducción a las vulnerabilidades de formato de cadena, 2 de mayo de 2013, por Alex Reece
• scut / equipo- TESO Explotación de vulnerabilidades de formato de cadena v1.2 2001-09-09
• Clasificación de amenazas WASC - Ataques de formato de cadena
• Estándares de codificación segura CERT
• Iniciativa de codificación segura de CERT
• Vulnerabilidades conocidas en el proyecto CVE de MITRE.
• Programación segura con GCC y GLibc. Archivado el 21/11/2008 en Wayback Machine (2008), por Marcel Holtmann.