SmallerC scanf s Stack.md

SmallerC – Débordement de tampon de pile avec scanf %s

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

L'implémentation de scanf de SmallerC n'impose pas de limite supérieure sur les lectures de chaîne lorsque %s ou %[ est utilisé sans largeur de champ explicite dans la chaîne de format. Le runtime continue d'écrire dans le tampon de destination jusqu'à rencontrer un espace blanc ou EOF, indépendamment de la taille réelle allouée du tampon. Tout octet dépassant la limite tombe directement sur la pile, écrasant ce que le compilateur a placé au-dessus du tampon : variables locales, registres sauvegardés, adresse de retour.

Il ne s'agit pas d'une classe de vulnérabilité nouvelle. Les lectures de chaîne non bornées avec scanf sont documentées depuis les premiers jours du C, et tout outil d'analyse statique compétent les signalera. Ce qui rend ce problème notable dans le contexte spécifique de SmallerC est l'environnement cible. SmallerC est conçu pour DOS et les cibles embarquées « bare‑metal » – des plateformes qui, par définition, ne fournissent pas de canaries de pile, d'ASLR, de bits NX, ni aucune des atténuations qui rendent l'exploitation difficile sur les systèmes modernes. La même primitive qui nécessiterait un effort de recherche important pour être transformée en exploit fonctionnel sur un binaire Linux durci devient considérablement plus abordable sur un programme DOS fonctionnant sur une pile plate et prévisible.

Le tampon fait 16 octets. L'entrée est de 20 octets non blancs. La conversion %s n'a pas de spécificateur de largeur, donc sscanf lit les 20 octets plus un terminateur nul – 21 octets au total – dans une allocation de 16 octets. Les 5 octets au‑delà de la limite corrompent la mémoire contiguë de la pile. Ce qui est exactement corrompu dépend des décisions d'agencement de pile du compilateur pour cette fonction particulière, mais l'écrasement lui‑même est déterministe et inconditionnel à chaque exécution de ce chemin de code avec cette entrée.

Preuve de concept

#include <stdio.h>
#include <string.h>

/*
 * Compilation avec SmallerC ciblant DOS ou bare‑metal
 * Démontre une écriture %s non bornée au‑delà d'un tampon de pile fixe
 *
 * buffer fait 16 octets, payload fait 20 octets non blancs
 * sscanf écrit 21 octets (20 + terminateur nul) dans buffer
 * corrompant 5 octets de la mémoire de pile adjacente
 *
 * Pour observer la corruption, inspectez la mémoire de pile après l'appel :
 * les 5 octets immédiatement au‑dessus de buffer contiendront 'A' (0x41)
 */

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

    memset(buffer, 0x00, sizeof(buffer));
    memset(canary, 0xCC, sizeof(canary));  /* marqueur pour détecter l'écrasement */

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

    sscanf("AAAAAAAAAAAAAAAAAAAA", "%s", buffer);  /* 20 octets dans un tampon de 16 octets */

    printf("[*] canary après :  ");
    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("[!] corruption de pile confirmée – canary écrasé\n");
    else
        printf("[-] canary intact (l'agencement de pile l'a placé ailleurs)\n");

    return 0;
}

Sortie attendue sur un build affecté :

[*] canary avant : cc cc cc cc cc cc cc cc
[*] canary après :  41 41 41 41 41 cc cc cc
[!] corruption de pile confirmée – canary écrasé

Le placement du canary par rapport à buffer dépend de l'agencement de pile du compilateur. Si la sortie montre le canary intact, l'écrasement a quand même lieu – il atterrit sur autre chose au‑dessus du tampon. Adaptez le reproducteur en inspectant la véritable trame de pile avec un débogueur pour localiser où les 5 octets corrompus tombent.

Une correction qui mérite d'être explicitement mentionnée : certains rapports de cette classe de vulnérabilité tentent de démontrer le contrôle de l'adresse de retour en ajoutant une adresse cible après un octet nul dans le payload, comme "AAAAAAAAAAAAAAAAAAA\x00\x90\x04\x08". Cela ne fonctionne pas. La conversion %s dans sscanf traite \x00 comme un terminateur de chaîne et cesse de lire immédiatement lorsqu'elle le rencontre. Les octets suivant l'octet nul ne sont jamais traités. Démontrer un véritable contrôle de l'adresse de retour nécessite de délivrer l'écrasement sans octet nul dans la portion critique du payload, ce qui exige de connaître l'agencement exact de la pile du binaire cible – la distance du tampon à l'adresse de retour sauvegardée, si le compilateur a inséré du padding, et quelles contraintes d'alignement s'appliquent. Rien de tout cela ne découle automatiquement de ce reproducteur.

Ce que le reproducteur établit clairement, c'est la primitive de corruption elle‑même. L'écriture hors limites est réelle, reproductible et ne dépend d'aucune condition de course ou de timing. Sur une cible DOS ou embarquée où l'agencement de pile est statique et prévisible entre les builds, passer de cette primitive à un exploit fonctionnel est un effort de recherche réaliste, et non un exercice théorique.

Le scénario affecté est étroit mais pas artificiel. Un programme doit être compilé avec SmallerC, utiliser l'analyse de type scanf avec un spécificateur %s ou %[ non borné, écrire dans un tampon de pile de taille fixe, et accepter une entrée provenant d'une source que l'attaquant peut influencer. Les quatre conditions doivent être simultanément remplies. Les programmes qui utilisent des largeurs de champ correctes – %15s pour un char[16] – ne sont pas affectés. Les programmes qui n'analysent pas d'entrée contrôlée par l'attaquant ne sont pas affectés. Le problème est un défaut dans la gestion par le runtime de SmallerC de la contrainte de largeur manquante, mais il ne devient un problème de sécurité que lorsque le code applicatif expose ce défaut à une entrée non fiable.

Du côté applicatif, la correction est simple : spécifier une largeur de champ qui laisse de la place pour le terminateur nul. %15s pour un tampon de 16 octets, %63s pour un tampon de 64 octets. C'est une pratique C standard et entièrement supportée par la syntaxe de chaîne de format. Du côté du projet SmallerC, le travail plus durable consiste à ajouter des tests de régression couvrant à la fois les comportements bornés et non bornés de %s et %[ dans scanf, sscanf et fscanf, en vérifiant que les largeurs de champ explicites sont effectivement respectées dans l'implémentation, et à documenter clairement le motif dangereux. Un diagnostic au niveau du compilateur qui avertit lorsque %s ou %[ apparaît sans largeur de champ dans un littéral de chaîne de format préviendrait proactivement cette classe d'erreurs et constituerait un ajout significatif à la chaîne d'outils.

La gravité est Moyenne lorsqu'une entrée externe atteint le chemin de code vulnérable. Elle tombe à Faible lorsque l'entrée est locale ou non privilégiée. L'environnement cible – spécifiquement l'absence d'atténuations d'exploitation modernes sur les plateformes destinées à SmallerC – est ce qui distingue ce conseil générique « n'utilisez pas scanf non borné » et rend ce signalement pertinent au niveau du projet plutôt que de le traiter uniquement comme un mauvais usage au niveau applicatif.

Crédit : Yousif Wazni