SmallerC scanf s Stack.md

SmallerC - Desbordamiento de búfer de pila en scanf %s

Proyecto: https://github.com/alexfru/SmallerC

La implementación de scanf de SmallerC no impone un límite superior en las lecturas de cadenas cuando se usa %s o %[ sin un ancho de campo explícito en la cadena de formato. El runtime continúa escribiendo en el búfer de destino hasta que encuentra un espacio en blanco o EOF, independientemente del tamaño real asignado al búfer. Cualquier byte que sobrepase el límite cae directamente en la pila, sobrescribiendo lo que el compilador haya colocado por encima del búfer: variables locales, registros guardados y la dirección de retorno.

Esta no es una clase de vulnerabilidad novedosa. Las lecturas de cadenas sin límite en scanf están documentadas desde los primeros días de C, y cualquier herramienta competente de análisis estático las señalará. Lo que hace que valga la pena reportar esto en el contexto específico de SmallerC es el entorno objetivo. SmallerC está diseñado para DOS y objetivos embebidos bare-metal: plataformas que, por definición, no ofrecen canarios de pila, ASLR, bits NX ni ninguna de las mitigaciones que dificultan la explotación en los sistemas modernos. La misma primitiva que requeriría un esfuerzo de investigación significativo para convertirla en un exploit funcional en un binario Linux endurecido se vuelve considerablemente más manejable en un programa DOS que se ejecuta en una pila plana y predecible.

El búfer es de 16 bytes. La entrada es de 20 bytes sin espacios en blanco. La conversión %s no tiene especificador de ancho, por lo que sscanf lee los 20 bytes más un terminador nulo (21 bytes en total) en una asignación de 16 bytes. Los 5 bytes que sobrepasan el límite corrompen la memoria de pila adyacente. Qué se corrompe exactamente depende de las decisiones del compilador sobre el diseño de pila para esa función en particular, pero la sobrescritura en sí es determinista e incondicional cada vez que esta ruta de código se ejecuta con esta entrada.

Prueba de concepto

#include <stdioh>
#include <stringh>

/*
 * Build with SmallerC targeting DOS or bare-metal
 * Demonstrates unbounded %s write past a fixed stack buffer
 *
 * buffer is 16 bytes payload is 20 non-whitespace bytes
 * sscanf writes 21 bytes (20 + null terminator) into buffer
 * corrupting 5 bytes of adjacent stack memory
 *
 * To observe the corruption inspect stack memory after the call:
 * the 5 bytes immediately above buffer will contain 'A' (0x41)
 */

int main() {
    char buffer[16];
    char canary[8];

    memset(buffer 0x00 sizeof(buffer));
    memset(canary 0xCC sizeof(canary));  /* marker to detect overwrite */

    printf("[*] canary before: ");
    for (int i = 0; i < 8; i++) printf("%02x " (unsigned char)canary[i]);
    printf("\n");

    sscanf("AAAAAAAAAAAAAAAAAAAA" "%s" buffer);  /* 20 bytes into 16-byte buffer */

    printf("[*] canary after:  ");
    for (int i = 0; i < 8; i++) printf("%02x " (unsigned char)canary[i]);
    printf("\n");

    if (memcmp(canary "\xCC\xCC\xCC\xCC\xCC\xCC\xCC\xCC" 8) != 0)
        printf("[!] stack corruption confirmed  canary overwritten\n");
    else
        printf("[-] canary intact (stack layout placed it elsewhere)\n");

    return 0;
}

Salida esperada en una compilación afectada:

[*] canary before: cc cc cc cc cc cc cc cc
[*] canary after:  41 41 41 41 41 cc cc cc
[!] stack corruption confirmed  canary overwritten

La ubicación del canario en relación con el búfer depende del diseño de pila del compilador. Si la salida muestra el canario intacto, la sobrescritura sigue ocurriendo; está aterrizando en otra cosa por encima del búfer. Ajusta el reproductor inspeccionando el marco de pila real con un depurador para localizar dónde aterrizan los 5 bytes corruptos.

Una corrección que vale la pena hacer explícita: algunos informes de esta clase de vulnerabilidad intentan demostrar el control de la dirección de retorno añadiendo una dirección objetivo después de un byte nulo en la carga útil, como "AAAAAAAAAAAAAAAAAAA\x00\x90\x04\x08". Esto no funciona. La conversión %s en sscanf trata \x00 como un terminador de cadena y deja de leer inmediatamente cuando lo encuentra. Los bytes que siguen al byte nulo nunca se procesan. Demostrar el control real de la dirección de retorno requiere entregar la sobrescritura sin un byte nulo en la porción crítica de la carga útil, lo que a su vez requiere conocer el diseño exacto de la pila del binario objetivo: la distancia entre el búfer y la dirección de retorno guardada, si el compilador insertó algún relleno y qué restricciones de alineación se aplican. Nada de eso surge automáticamente de este reproductor.

Lo que el reproductor establece limpiamente es la primitiva de corrupción en sí misma. La escritura fuera de límites es real, reproducible y no depende de ninguna condición de carrera ni de temporización. En un objetivo DOS o embebido donde el diseño de pila es estático y predecible entre compilaciones, pasar de esta primitiva a un exploit funcional es un esfuerzo de investigación realista, más que un ejercicio teórico.

El escenario afectado es limitado, pero no artificial. Un programa debe estar compilado con SmallerC, usar el análisis de la familia scanf con un especificador %s o %[ sin límite, escribir en un búfer de pila de tamaño fijo y aceptar entrada de una fuente que el atacante pueda influenciar. Las cuatro condiciones deben cumplirse simultáneamente. Los programas que usan anchos de campo correctos (%15s para un char[16]) no se ven afectados. Los programas que no analizan entrada controlada por el atacante no se ven afectados. El problema es un defecto en cómo el runtime de SmallerC maneja la restricción de ancho faltante, pero solo se convierte en una preocupación de seguridad cuando el código de la aplicación expone ese defecto a entrada no confiable.

En el lado de la aplicación, la solución es sencilla: especifica un ancho de campo que deje espacio para el terminador nulo: %15s para un búfer de 16 bytes, %63s para un búfer de 64 bytes. Esto es práctica estándar de C y está totalmente soportado por la sintaxis de las cadenas de formato. En el lado del proyecto SmallerC, el trabajo más duradero es añadir pruebas de regresión que cubran el comportamiento de %s y %[ tanto con límite como sin límite en scanf, sscanf y fscanf, verificando que los anchos de campo explícitos realmente se respetan en la implementación y documentando el patrón inseguro de manera prominente. Un diagnóstico a nivel de compilador que advierta cuando %s o %[ aparezca sin un ancho de campo en un literal de cadena de formato preveniría esta clase de error de forma proactiva y sería una adición significativa al toolchain.

La severidad es Media cuando la entrada externa llega a la ruta de código vulnerable. Desciende a Baja cuando la entrada es local o sin privilegios. El entorno objetivo —específicamente, la ausencia de mitigaciones modernas de explotación en las plataformas previstas de SmallerC— es lo que separa esto de un aviso genérico de «no uses scanf sin límite» y hace que valga la pena reportarlo a nivel de proyecto en lugar de tratarlo puramente como un mal uso de la capa de aplicación.

Crédito: Yousif Wazni