Jonathan Brossard, Fondateur de Moabi
Moabi est un service Français dont l’unique fonction est de découvrir des vulnérabilités exploitables dans n’importe quel type d’exécutable.
Voilà pour la version résumée. Dans le détail, c’est une machinerie SaaS complexe, « résultat d’années de recherches, de développement » assure son fondateur, Jonathan Brossard. Cette machinerie est une usine à exécution symbolique capable de traiter n’importe quel type de programme (compilé), destiné à n’importe quel type de processeur. Or, cette notion d’exécution symbolique fait partie des vieilles chimères des recherches universitaires. Trop lourde, trop lente, trop théorique, elle est longtemps demeurée dans les limbes du devenir, à côté d’autres idées révolutionnaires comme le calcul quantique et l’intelligence artificielle de HAL 9000. Mais ça, c’était avant l’arrivée sur le marché de capacités de calcul monstrueuses des vendeurs de Cloud.
Il existe plusieurs méthodes de « chasse au bug ». La plus classique consiste à analyser un programme qui s’exécute dans une machine -virtuelle ou réelle-, avec son système d’exploitation, ses bibliothèques de fonctions, ses variables… et dont les tests se limitent à vérifier que le moteur tourne rond dans des conditions normales, un test de premier niveau qui garantie en grande partie la validité des clauses de saisie, la conformité de certains points (randomisation ASLR, validation des signatures, conformité des API appelées …)
Une autre approche consiste à analyser le code source et extrapoler les déviances prévisibles provoquées par le compilateur. Des outils coûteux, exigeants en termes de compétences techniques, très liés (et pour cause) au type de langage utilisé. Seuls les Microsoft, les Apple, les Amazon et consorts ont les moyens financiers, les ressources humaines et le temps d’utiliser ces panoplies pour debugger en eaux profondes.
L’exécution symbolique, quant à elle, ne tient compte directement ni de l’environnement (système d’exploitation), ni des dépendances tierces et ne s’attache qu’aux symboles. Lorsque le programme est lancé, toutes les possibilités d’exécution et les appels du programme sont testées, et non seules celles rendues possible par le système. La connaissance du ou des langages entrant dans sa composition est donc relativement secondaire, puisque seul le résultat post-compilation est torturé (un .exe, une dll, mais également un elf, voir un .hex prévu pour être buriné dans le silicium d’un microcontrôleur).
On s’en doute, être capable d’analyser aussi bien un code X86, Motorola, Zilog ou ARM que celui destiné à une plateforme Atmel ou une gpu Nvidia a nécessité quelques années de travail pour forger ces multiples environnements d’exécution. Mais une exécution indépendante de tout système, une analyse qui ne se focalise que sur les défauts exploitables. Une exécution, enfin, qui n’exige pas une équipe de gourous surspécialisés puisque l’accès à ces exécuteurs symboliques s’opère par abonnement à un service.
Nguyen Hung Vu
Le secret des sources sans les risques
A qui s’adresse Moabi ? En priorité, à toute entreprise, à tout intégrateur qui redoute la moindre panne binaire sur un binaire dont ils ne possèdent pas le source. C’est le cas notamment des OEM dans le secteur de l’automobile de seconde monte et de l’embarqué à faible coût, de l’automatisme industriel (rares sont les constructeurs d’automates programmables qui fournissent leurs codes, encore plus rares sont les entreprises utilisatrices qui les demandent).
C’est également une solution élégante pour un éditeur qui rêve de faire qualifier un programme en garantissant un niveau de sécurité sans avoir à dévoiler ses secrets de fabrication et risquer la perte de sa propriété intellectuelle.
C’est enfin le dernier garde-fou dans les domaines où la sécurité et la fiabilité des systèmes priment avant tout : informatique embarquée militaire ou civile, aviation, spatial, transports et autres infrastructures Scada. Car même en possédant les sources d’un programme, il est n’est pas toujours possible de détecter une saturation de tampon, une faille XSS, un défaut inhérent non pas au code mais au compilateur ou à l’éditeur de liens. Moabi est donc, dans ce cas, non plus seulement un automate de chasse aux bugs, mais un outil de certification qui quantifie le niveau de qualité du programme en plusieurs points : conformité du chiffrement, du durcissement du programme, de sa conception générale et sa résilience selon les référentiels (posix, CE99…), sa salubrité générale notamment envers les failles référencées dans l’index CVE ou les trous non encore répertoriés et mis en évidence durant l’exécution, sans oublier des points plus triviaux tels que le respect des règles imposées par l’environnement d’exécution ou les contraintes du processeur.
Malgré une technique prometteuse, l’exécution symbolique se heurte tout de même à deux écueils de taille. D’une part, l’énorme difficulté à vulgariser la notion même de symbole, y compris auprès des professionnels de la SSI. D’autre part, l’indifférence dont fera preuve l’immense majorité des acteurs de l’électronique de grande consommation, dont le cycle de vie de développement se compte en mois, voire en semaines. Ce sont les industriels de l’IoT importé d’Orient, les armées de développeurs qui travaillent en mode « quick and dirty » et qui jamais n’investiront le moindre centime en contrôle-qualité logicielle, en raison de marges réduites à l’extrême, de contraintes « time to market » étriquées et d’absence totale de support clientèle. Cela va du traceur GPS à la caméra de surveillance domotique, de la montre fitness à 20 euros à la poupée électronique interactive. Le jour où Moabi aura convaincu les principaux géants du logiciel et du firmware, les organisateurs des conférences « InfoSec » auront du souci à se faire pour remplir leurs programmes de « sploits » spectaculaires, craquants sous la dent des hackers et reversers.
