MISC Hors-série N°

Numéro

30

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 !

Le but de cet article est de mettre en lumière les RFC 9421 et 9530 qui normalisent la signature des requêtes/réponses HTTP. Ces normes autorisent à améliorer grandement la sécurité des appels REST afin de garantir l’intégrité, la non-répudiation et la provenance des réponses.

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.

Les integer overflow ou wraparound, ou CWE-190 pour les intimes, sont une vulnérabilité présente en programmation depuis des décennies. Elle se produit lorsqu’une opération arithmétique tente de créer une valeur numérique supérieure à la valeur maximale ou inférieure à la valeur minimale pouvant être représentée dans l'espace de stockage alloué pour un type de données entier. Elle « déborde ».

Ou plus spécifiquement, ne déréférencez en aucun cas un pointeur après un free ! Facile ? L'utilisation de pointeurs après leur libération (Use After Free) fait toujours aujourd'hui partie du top 5 des vulnérabilités listées par MITRE (https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html). Avec des conséquences qui peuvent aller du crash de l'application à l'exploitation de la vulnérabilité induite par un attaquant, et, au final, avoir un impact sur votre réputation ou vous coûter beaucoup d'argent ! Dans cet article, nous verrons quelques cas dont il faut se méfier, comment les Use After Free constituent des vulnérabilités qui peuvent être exploitées par des attaquants, et surtout les mesures à mettre en place pour les éviter autant que possible.

L’histoire, ou plutôt l’Histoire, est une coquine. Et quand Dennis Ritchie et Ken Thompson inventent le langage C en 1972, ils prennent une décision anodine, une micro-optimisation qui fait gagner quelques octets, mais qui aura un impact important sur la sécurité de nombreux systèmes : en C, les chaînes de caractères sont terminées par un octet positionné à zéro.

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.

Il y a 19 ans, Ulrich Drepper, alors développeur chez Red Hat et un des contributeurs principaux de la glibc, ajoutait au changelog de la glibc la ligne suivante : sysdeps/i386/bsd-_setjmp.S: Use PTR_MANGLE for PC if defined, inaugurant ainsi l’arrivée de la protection des pointeurs de fonction stockés dans des structures internes à la glibc.

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 2014, un groupe de chercheurs en sécurité a découvert une vulnérabilité dans l’extension du Heartbeat TLS dans OpenSSL : elle permettait de révéler jusqu’à 64 Ko de mémoire du processus. Ce bug, connu sous le nom de Heartbleed, était le résultat d'une erreur de programmation assez courante, mais difficile à repérer, ce qui permettait de lire en dehors des limites d’un tampon.Les lectures en dehors des limites du tampon (ou out-of-bound read) permettent de divulguer des informations privées et aussi de rendre fiable l’exploit d’autres vulnérabilités.Dans cet article, on parlera des cas typiques de ce bug, des contre-mesures classiques et de leur contrepartie en vulnérabilité hardware.

Le combat pour rendre l’exploitation de bugs passe entre autres par rendre la réutilisation de code de plus en plus difficile. Pointer Authentication Code (PAC) est une extension apparue avec l’architecture ARMv8.3 en mars 2016 et qui va dans ce sens. Elle est notoirement utilisée dans tous les appareils récents de la marque Apple. Regardons comment cette extension rend effectivement la vie des attaquants plus complexe.

Quand il est question d'identifier les différentes techniques qu'un attaquant peut mobiliser pour contrôler un processus ou en extraire des données, il est intéressant de mentionner ptrace(2). Rien de révolutionnaire ici, étant donné que cet appel système est présent depuis UNIX version 6 [1]. Pour ainsi dire : une éternité. Néanmoins, cet appel système fournit tous les outils nécessaires à une attaque s’il est utilisable, il est donc important de le connaître, d’en connaître ses limites et de savoir s’en prémunir au besoin.

« Pour être efficace, il faut cacher ses intentions. » (N. Machiavel, 1527). Dans l’univers des malwares, il existe un type de menace spécifique dont le but est entre autres de dissimuler sa présence afin d'utiliser les ressources de la machine infectée : les rootkits. Une des nombreuses techniques sous-jacentes est le DLL hijacking.

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.