Guelton Serge

Continuons cette série sur les codes fantastiques en compagnie de noms de variables écrits en Unicode.

Le langage C est un magnifique outil pédagogique pour enseigner le concept de mémoire, puisqu’il laisse la main au développeur pour la gérer. Mais on le sait, cet attrait n’en est pas un quand on parle de sûreté d’exécution, puisque ce langage est connu pour ne pas aider le développeur pour détecter les usages illégaux liés à la mémoire. Le langage Rust a attaqué le problème en rendant explicite le concept de durée de vie. Le langage Safe C++ tente quant à lui d’introduire ce concept en C++. Il y a plus de vingt ans, splint proposait déjà un concept moins ambitieux pour C. Et maintenant certains fous essaient de le porter vers C++, à travers des extensions de Clang. Quelles sont donc toutes ces approches ?

Continuons cette série sur les codes fantastiques avec une surprise qui nous est offerte par le shell POSIX.

Continuons cette série sur les codes fantastiques avec une optimisation inattendue de l’éditeur de liens.

Continuons cette série sur les codes fantastiques avec un problème apparemment simple : calculer la moyenne de deux entiers.

Continuons cette série sur les codes fantastiques avec deux drapeaux qui interagissent avec l’interposition de symboles.

En 1996, Aleph One publiait dans l’e-zine Phrack un article intitulé « Smashing the Stack for Fun and Profit ». C’était il y a plus de 25 ans et les principes énoncés dans cet article sont toujours valides, même si leur exploitation est devenue plus technique.De manière plus conventionnelle, l’écriture dans une zone mémoire non-autorisée est un vecteur d’attaque classique connu sous le doux nom de CWE-787.Dans cet article, on se concentrera sur les attaques ciblant la pile, en détaillant quelques bugs classiques, leur exploitation historique et quelques contre-mesures qui ont été mises en place au fil du temps.

En regardant la liste des 25 failles les plus dangereuses éditées par MITRE chaque année, on ne peut qu’être frappé par la présence (ou la persistance) de thèmes bien connus : écriture illégale dans une zone mémoire, utilisation d’une zone mémoire désallouée, lecture illégale d’une zone mémoire, déréférencement de pointeur NULL, dépassement de la capacité d’un entier… Autant de sujets qui sont pourtant abordés dans les premiers chapitres de tout bouquin traitant de la sécurité logicielle. Ce qui n’en fait pas pour autant des sujets faciles dès lors que les considérations de base de code existant et de performances rentrent en compte. C’est compliqué l’optimisation multicritère !

La fonction system(3), disponible dans la bibliothèque C standard et standardisée dès C89, est symptomatique d’une époque où la sécurité n’était pas la priorité des développeurs. La lecture de sa page de manuel est pleine d’avertissements, qui sont autant d’enseignements potentiels. Allez, c’est parti, man 3 system.