14,59 € TTC
p. 06 Je signe ou je tamponne ? Ni l’un ni l’autre, vous contresignez
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
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
Face à la transformation digitale de notre société et l’augmentation des cybermenaces, la cybersécurité doit être aujourd’hui une priorité pour bon nombre d’organisations. Après plus de 20 années de publications et de retours d’expérience, MISC apporte un vivier d’informations techniques incontournable pour mieux appréhender ce domaine. Précurseur sur ce terrain, MISC a été fondé dès 2002 et s’est peu à peu imposé dans la presse française comme la publication de référence technique en matière de sécurité informatique. Tous les deux mois, ses articles rédigés par des experts du milieu vous permettront de mieux cerner la complexité des systèmes d’information et les problèmes de sécurité qui l’accompagne.
La sécurité des codes… En voilà un sujet fourre-tout où n’importe quel article de MISC trouverait sa place ! Pour apporter une petite touche personnelle, et faire un petit clin d’œil à mon héritage familial, j’ai choisi de prendre un axe historique pour la constitution de ce dossier.
C, C++, Python, ADA, Ruby, Java, Rust, MISRA-C, Swift et j’en passe. Autant de noms de langages qui se voient associés pour leur plus grand bien ou pour leur malheur à la question de la sécurité. Ou de la sûreté. Ou les deux. En cinquante ans, les besoins ont évolué et avec eux les contraintes auxquelles les développeurs — et donc les langages qu’ils utilisent — sont soumis. Petite rétrospective à travers différents langages qui ont, ou ont eu, leur heure de gloire.
Le jeu du chat et de la souris : c’est ce qui résume le plus le combat que mènent les analystes contre les cybercriminels, où chaque partie cherche à devancer l’autre : sauf que les attaquants ont souvent (toujours ?) une longueur d’avance. Dans ce contexte, diverses techniques sont utilisées par les attaquants pour éviter de se faire détecter. Parmi elles, la menace des fileless malware plane : ils posent un défi majeur pour la cybersécurité. Cet article explore les techniques d’infection, les méthodes de détection, et fournit des conseils pratiques pour renforcer la défense des infrastructures informatiques.