lundi 20 juin 2016

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.

13 commentaires:

Anonyme a dit…

Merci :]

(satisfait ou remboursé ?)

Fred a dit…

Boum, dans ta face Armadito. En même temps, personne ne parlera de ce scandale, de cette magouille légitimée par les autorités.

Greg a dit…

La question est de savoir pourquoi alors les israéliens arrivent à etre autant dynamique avec des thesards qui travaillent pendant 3 ans pendant le service et apres lancent des startups avec des produits interessants.

Peut etre est ce parce qu'ils passent trois ans et que leur produit est directement voue a etre operationnel?


Anonyme a dit…

J'ai du mal à comprendre que Bit9 soit cité en exemple, sur des traitements lourds (genre build), la pénalité d’exécution peut être de plus de 100% (temps de traitement doublé ou triplé). Pour un poste de développeur, c'est "au delà" du pénible.

newsoft a dit…

Il me semble que le cas du "poste du développeur" est très particulier ; un antivirus grand public n'a pas à le supporter explicitement. Au pire il suffit de mettre en liste blanche ..\Visual Studio 2015\*.

newsoft a dit…

En ce qui concerne tous les commentaires de type "c'est de la fraude" ou "c'est du détournement de fonds publics", je ne peux bien évidemment pas les laisser passer (ça serait de la diffamation, au mieux).

SecuriteOff a dit…

Bonjour

trop dur de trouver l'article sur notre site... : http://www.securiteoff.com/fin-et-bilan-du-projet-davfi/


La rédaction de SecuriteOff


PS : au moins, celui-ci vous n'aurez pas eu la peine de l'acheter à l'unité ;-)

newsoft a dit…

Merci, c'est corrigé.

Dnucna a dit…

En fait, on manque (enfin, moi j'en manque) d'exemples concrets de bons investissements de l'Etat. Ce n'est pas Andromède, le Cloud souverain, qui peut redorer leur blason https://fr.wikipedia.org/wiki/Androm%C3%A8de_(cloud)

Le crédit import recherche me semble détourné de son but initial. Dans les SSII, il y a des formations pour pondre un slideware suite à un projet pour faire croire qu'il y a eu de la R&D. Rien qu'installer une maquette et faire un PoC d'une solution sur étagère est éligible au CIR... Et hop on a une prime sans rien partager avec la communauté.

Securiteoff Editions a dit…

Bonjour

"L'éditeur n'a pas jugé utile de rediriger les favoris antérieurs à la refonte du site (circa septembre 2015)." : nous attendons toujours que vous nous indiquiez votre source pour affirmer ceci ?

Nous tenons à préciser que cette information est fausse. Vous avez ajouté cette phrase dans votre article après notre précédent commentaire précisant que l’articule en question était bel et bien en ligne. Et vous avez cru bon d'avoir le dernier mot en ajoutant votre EDIT...



La direction de SecuriteOff

Anonyme a dit…

Hey Philou de "La-direction-de-SecuriteOff-qui-ne-comprend-qu'une-seule-et-unique-personne-mais-ça-fait-toujours-mieux-de-faire-croire-qu'on-est-50",

Ce tweet de 2014 montre que c'est bien newsoft qui a le dernier mot ;)

https://twitter.com/newsoft/status/519059907526811648

Bisous,

SafestSneer

newsoft a dit…

@SecuriteOff Editions,

Je vous ai déjà répondu sur Twitter (https://twitter.com/newsoft/status/744995065207099397) mais le format blog va me mettre une réponse plus circonstanciée.

Le lien d'origine fonctionnait au 1er octobre 2014, comme en atteste Wikipedia: https://fr.wikipedia.org/wiki/Uhuru_(antivirus)#cite_note-4

Lors d'une mise à jour ultérieure du site, ce lien est devenu non fonctionnel, sans redirection vers le nouvel article.

Bien entendu il peut s'agir d'une erreur, mais je ne juge pas l'intention. Je dis simplement que votre site ayant la politique explicite de ne pas être indexé par les moteurs de recherche (http://securiteoff.com/robots.txt), il est impossible de découvrir le nouvel article sauf à en connaitre l'existence *et* à utiliser le moteur de recherche interne de votre site. Ce qui limite fortement sa visibilité, d'ailleurs le nouveau lien m'avait échappé en toute bonne foi.

A contrario, les deux autres articles n'ont pas changé d'adresse et bénéficient de liens courts toujours valides:
http://url.exen.fr/106338/
http://url.exen.fr/107683/

Je ne pense pas que cette polémique apporte grand'chose sur le fond, mais au moins vous disposez désormais de tous les éléments techniques pour comprendre ma démarche.

Anonyme a dit…

Newsoft et SecuriteOff règlent leurs comptes en public pour une histoire de lien... Après cette brillante démonstration, ils critiquent une tentative industrielle qui a , à tort, embarqué un caractériel notoire et ne pouvait donc se terminer que par un fiasco...