Guelton Serge

Pour commencer cette série sur les codes fantastiques, nous allons faire un petit tour dans la page de manuel de dlopen et (re)découvrir une forme d’introspection au niveau bibliothèque partagée.

Aux dernières vacances de février, j'ai eu l'opportunité de contribuer au CTF d'Insomnihack sous la forme d'un challenge de reverse. Si j'ai eu beaucoup de joie lors de son écriture, et malgré des retours positifs de la part des participants, celui-ci souffrait d'un défaut majeur. Cet article est donc une sorte de rapport de chall' par l'auteur, commentaire de texte inclus !

Machines et développeurs ont parfois du mal à communiquer. D’un côté l’esprit humain, avec sa volonté d’abstraire et de penser fonctionnel. De l’autre côté, la machine et sa froide rigueur électronique. Entre les deux, il y a un pont : le compilateur. Mais comment prend-il en compte les aspects sécurité ?

Le premier novembre 2021, les CVE-2021-42574 et CVE-2021-42694 étaient rendues publiques. Ces deux CVE rendent comptent des limitations de l’utilisation de caractères Unicode dans les identifiants, commentaires et/ou chaînes de caractères littérales de codes sources. Elles sont intéressantes par deux aspects : elles sont relativement agnostiques au langage de programmation sous-jacent, et elles utilisent comme cheval de Troie le rendu fait par certains outils, notamment les forges logicielles en ligne, de certains caractères Unicode.

Dans le hors-série 24 de MISC [0], nous avions montré que les outils et techniques de la compilation sont aujourd'hui des éléments incontournables dans le domaine de la sécurité des applications, que ce soit pour les protéger, les obfusquer, et même de manière plus surprenante les reverser.Nous plongeons ici plus en détail dans les entrailles d'un compilateur, Clang/LLVM [LLVM] : ses différentes étapes, son architecture, sa représentation interne, ses optimisations. Nous illustrerons les transformations les plus communes par un exemple concret, et nous verrons que si certaines structures de code observées dans les binaires sont facilement reconnaissables, d'autres peuvent surprendre...

Cet article s'inscrit dans la continuation d'une série d'articles sur les artefacts bas niveau que l'on peut rencontrer dans un binaire compilé à partir de sources en C++. Cet épisode aborde (enfin !) un des morceaux les plus indigestes de la traduction de C++ en assembleur : la gestion d'exceptions sous Linux, suivant la spécification dite Itanium.

On trouve des compilateurs partout : quand on construit des programmes, bien sûr, mais aussi quand on visite la page web des Éditions Diamond — elle embarque du JavaScript, qui est probablement compilé à la volée par un composant de votre navigateur. Quand on utilise un Notebook Jupyter pour du calcul scientifique — ne serait-ce que pour la compilation en bytecode du source Python. Quand on installe un APK pour ART, celui-ci est transformé en code natif depuis son bytecode Dalvik… encore de la compilation. Et nous allons voir que le domaine de la compilation peut aussi très largement intéresser celui de la sécurité informatique et du reverse engineering.

En sécurité sous les drapeaux... du compilateur, ces fameux -fstack-protector-strong et autres -D_FORTIFY_SOURCE=2 que l’on retrouve dans de plus en plus de logs de compilation. Cet article se propose de parcourir quelques-uns des drapeaux les plus célèbres, en observant les artefacts dans le code généré qui peuvent indiquer leur utilisation, tout en discutant de leur support par gcc et clang. Après tout, nombre d’entre eux sont utilisés par défaut sous Debian ou Fedora, ils méritent bien qu’on s’y intéresse un peu.

Cet article est le troisième d'une mini-série sur le C++, ou plutôt sur les binaires compilés depuis C++, leurs particularités, comment les concepts du langage se retrouvent parfois dans le binaire final.