Web

p. 06   Je signe ou je tamponne ? Ni l’un ni l’autre, vous contresignez

Dossier : Sécurisez vos codes

p. 23   Introduction au dossier
p. 24   Lala langue
p. 36   Ça déborde là, non ?
p. 42   Attention : pointeur libéré !
p. 54   Des soucis à la chaîne
p. 60   Un problème systémique
p. 64   Garder ses parties privées
p. 66   Smash Bros
p. 72   Rien de secret dans la mémoire
p. 78   Pointer Authentication Code (PAC)
p. 90   PTrace me if you can
p. 98   Rootkit et DLL Hijacking

Malware

p. 102  Fileless malware : comprendre et mitiger les attaques

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 !

Parce que oui, vérifier tous les accès mémoires à l’exécution, instrumenter toutes les instructions pour s’assurer de leur validité, s’exécuter dans un bac à sable, tout cela est déjà possible. Choix du langage, utilisation des bonnes options de compilation ou utilisation d’environnements d’exécution contraints, on sait durcir des programmes. Mais à quel prix ! Il y a un coût en temps d’exécution du programme, en énergie utilisée, en taille de programme… Et puis il y a un coût plus sournois, le coût du savoir-faire.

Et avant même de savoir faire, il faut… savoir. Être conscient du risque, de savoir que l’on entre dans une zone rouge. Savoir qu’un appel à system(3) demande de protéger ses entrées, que, non, l’ordre de déclaration de variables locales en C ne donne aucune garantie sur leur ordre dans la pile (histoire vécue). Il n’est en fait pas même nécessaire de savoir résoudre le problème : savoir que le choix d’un langage, d’une option de compilation ou d’une bibliothèque a un impact sur la sécurité d’un logiciel est déjà une étape.

Alors plutôt que de chercher des solutions (et puis soyons honnêtes avec nous-mêmes, si elles étaient simples, on peut imaginer qu’elles seraient déjà déployées depuis longtemps), on peut s’inspirer des étudiants peintres en Chine pour lesquels reproduire les toiles des grands maîtres est une façon noble d’apprendre le métier. Parcourir la liste des vulnérabilités les plus classiques, les comprendre, s’émerveiller de la candeur de certains programmes, être surpris par la simplicité de certaines attaques ou par l’astuce de certaines approches, voilà une approche humble, réjouissante et studieuse qui pourrait s’avérer fructueuse.

L’étape suivante sera bien sûr d’écrire un petit code pour reproduire une attaque, pour le frisson. Parce que smashing the stack for fun and profit, ça sonne comme une activité de week-end plutôt sympathique. Mais là, quel drame, rien ne marche ! Avertissements du compilateur, pile non exécutable, adresses aléatoires... de nombreuses contre-mesures sont en fait déjà déployées et rendent notre tâche d’apprentissage plus ardue.

Plus ardue, mais pas impossible, sinon le classement MITRE ne serait pas ce qu’il est. Incroyable : le monde avance et la sécurité des programmes progresse. Dans ce numéro, on se propose finalement une tâche un peu vaine, mais pas moins amusante : comprendre les fondements des attaques les plus classiques, tout en sachant pertinemment que ce n’est que le premier pas d’un long trajet.

Serge Guelton
nullptr – serge.guelton@telecom-bretagne.eu