Le gâchis

Enfin ! Après 4 ans de travail et 5M€ de financement public, le projet d’antivirus « souverain » vient d’être publié sur GitHub.

Initialement connu sous le nom de DAVFI (Démonstrateurs d'AntiVirus Français et Internationaux), puis Uhuru Anti Malware (marque commerciale), le projet Open Source s’appelle désormais Armadito – est-ce un clin d’œil à la protection logicielle bien connue - mais désormais obsolète - « Armadillo » ?

Histoire

L’histoire de ce projet est controversée. Comme toute initiative dont la nationalité est la seule raison d’être, elle fut vertement critiquée à ses débuts. Et comme toutes les initiatives comparables, la malédiction n’a pas tardé à s’abattre : après avoir initié le développement du projet, puis transféré l’industrialisation (ainsi qu’un « personnel administratif senior » – en l’occurrence sa femme) au consortium porté par Nov’IT, M. Filiol a subitement fait volte-face et lâché ses chiens contre le projet Uhuru – allant même jusqu’à annoncer un « fork » Open Source sous le d’OpenDAVFI (dont on attend toujours la publication promise).

Ce drame franco-français n’est pas sans rappeler la mésaventure du « Cloud souverain », assez rapidement scindé en deux projets aussi infructueux l’un que l’autre. La dissension ne conduit généralement qu’au saupoudrage d’argent public.

Le divorce des « antivirus souverains » semble avoir été particulièrement douloureux, à en juger par les billets publiés sur le blog (payant) SecuriteOff : « Uhuru antimalware, a French deception » et « Les antivirus Uhuru, la grande mystification ». A contrario, le seul article positif – « Fin et bilan du projet DAVFI » - a disparu d’Internet (puisque le site n’autorise aucune indexation ni archivage de son contenu – à se demander qui sont ses lecteurs).

EDIT: l'article est toujours disponible à cette adresse. L'éditeur n'a pas jugé utile de rediriger les favoris antérieurs à la refonte du site (circa septembre 2015).

Technique

Il serait loisible mais peu charitable de se gausser des errements techniques du projet. Après tout nul n’est à l’abri d’une erreur d’implémentation.

Certes la librairie de « chiffrement » Perseus – censée protéger les SMS sur la version « Android » du projet – est régulièrement la risée des participants à la conférence SSTIC [2014][2015]. Le plus grave dans ces failles n’étant pas les détails d’implémentation, mais la méconnaissance répétée des mécanismes de génération d’aléa par son auteur ; pourtant l’un des fondamentaux de la cryptologie.

Certes la version « Android » du projet, publiée en 2014, a été immédiatement « cassée » de manière triviale : il était possible d’exécuter des commandes shell depuis la mire de démarrage du téléphone. Le plus grave a probablement été la réaction du projet, consistant à éditer agressivement la page Wikipedia dans une tentative désespérée de damage control.

Certes la version « Windows », récemment libérée sur GitHub, souffre de failles énormes – pour la plupart présentées lors BeeRump 2016 et dont j’espère la publication prochaine. Certains esprits taquins s’en sont même amusés publiquement. A cette liste s’ajoute la détection de codes malveillants dans les fichiers PDF par la recherche de motifs triviaux, ou l’incapacité totale à analyser des exécutables « .NET ».

L’essentiel des heuristiques « avancées » issues de la recherche en virologie consiste à comparer la liste des sections et des imports du fichier exécutable avec une base de référence, comprenant des fichiers « sains » et des fichiers « malveillants ». Il serait possible de se livrer à une analyse critique sur la méthode de calcul utilisée – et surtout l’importance de la base de référence – mais il s’agit d’un domaine technique ennuyeux pour le lectorat, qui est invité à chercher « import hash » dans son moteur favori (ou dépenser 35€ chez Springer).

Le véritable problème de cette heuristique, c’est qu’elle détecte plusieurs composants critiques du système Windows lui-même comme malveillants. Ce qui pose la question du contrôle qualité chez l’éditeur – le faux positif étant un événement essentiellement catastrophique.

Perspectives

Au-delà de l’idée assez classique des « import hash », le projet Armadito échoue à innover dans le domaine de la virologie opérationnelle.

Le principal reproche qu’on peut faire aux logiciels actuels est certainement l’accroissement de la surface d’attaque due aux nombreux parsers – qui ne sont malheureusement ni sandboxés, ni écrits en OCaml. Ce point est régulièrement mis en exergue par les travaux de Tavis Ormandy.

Un moteur d’analyse conçu pour résister à ses propres défauts – par exemple une sandbox pour ClamAV –  eut été un apport non négligeable à l’état de l’art, directement utilisable par la communauté. Au lieu de cela, les premiers tests de fuzzing semblent montrer une extrême fragilité du parser PDF – entièrement implémenté en C.

Parmi les autres idées dont on aurait pu se plaire à rêver, citons :

• La capacité à autoriser ou bloquer des processus selon des critères personnalisés, tels qu’une signature Authenticode (à la Bit9) ou une signature YARA - la fonctionnalité AppLocker offerte nativement par Windows étant bien trop limitée de ce point de vue.
• La capacité à journaliser et remonter en temps réel l’activité des processus sur une machine.
• Une API ouverte permettant d’interagir avec le moteur d’analyse, par exemple pour réaliser un hunt dans un parc étendu. L’intégration de cette API dans des outils standards tels que PowerShell serait un plus.
• Un kit de développement permettant l’extension du moteur avec des greffons – bien entendu sandboxés (à la Nessus, avec son langage NASL). Ceci permettrait également de créer une communauté autour du produit ; voire de pérenniser l’activité en commercialisant les greffons les plus complexes.
• Le support de vecteurs dangereux et peu analysés pour le moment, tels que les scripts PowerShell ou les macros Office.

Je n’aborde pas la question des signatures ; elle est à mon sens anecdotique. Les outils existants échouent systématiquement à détecter le dernier ransomware ou la dernière APT ; un modèle de sécurité basé sur des signatures (liste noire) est voué à l’échec face à des attaquants déterminés.

Conclusion

Confier le développement d’un logiciel – qui plus est de sécurité – à une armée mexicaine en partie composée de stagiaires et de thésards, n’ayant aucune expérience antérieure dans l’édition logicielle – ni la sécurité, ni aucune connaissance opérationnelle du monde de l’entreprise, sur la base de quelques travaux académiques à l’applicabilité douteuse : quelqu’un y croyait-il sérieusement ?

La seule explication rationnelle à l'existence de ce projet n'est probablement pas à chercher du côté de l'avancement de la science.