xiaoliangge - Fotolia
Sécurité : Huawei souffre de lacunes, mais il n’est pas le seul
Le centre d’évaluation de la sécurité de Huawei, piloté par le renseignement britannique, pointe des manques importants dans les processus de développement de l’équipementier. Mais il n’est pas forcément seul dans ce cas.
Le texte a de quoi paraître cinglant. Dans la nouvelle édition de son rapport annuel sur la sécurité des équipements Huawei, le centre chargé de l’évaluation de celle-ci, piloté par l’homologue anglais de l’Anssi, le NCSC et le renseignement britannique, le GCHQ, ne ménage pas ses reproches.
Cela commence par des défaillances dans le processus de compilation « qui doivent être rectifiés avant que l’équivalence binaire ne puisse être démontrée à l’échelle » : en somme, en l’état, impossible de s’assurer que le code source examiné est bien à l’origine du binaire exécuté sur les équipements.
Des reproches multiples
Pire encore, des problèmes encore liés à la compilation rendent « difficile d’être confiant que différents déploiements de mêmes équipements Huawei présentent globalement le même niveau de sécurité ».
Qui plus est, les efforts consentis par l’équipementier pour améliorer sa gestion des configurations « n’ont pas été universellement appliqués dans tous les groupes de développement de produits et de plateformes, ou dans tous les types d’éléments de configuration (code source, outils de compilation, scripts de compilation, etc.). Pour les auteurs, sans rigueur à ce niveau-là, « il ne peut pas y avoir d’intégré de bout en bout dans les produits livrés par Huawei ».
Les reproches ne s’arrêtent pas là et touchent plus globalement à la gestion du cycle de vie des composants logiciels de l’équipementier. Avec tout d’abord l’utilisation d’une version ancienne d’un « système d’exploitation temps réel bien connu et répandu » et bientôt en fin de support général. Certes, Huawei a signé un accord de support à long terme avec l’éditeur de ce système d’exploitation, mais les auteurs s’inquiètent de son architecture avec « un seul espace d’adressage, et un contexte utilisateur unique ». L’équipementier dispose de son propre équivalent à ce système d’exploitation, mais il est dit sujet aux problèmes plus globaux qui affectent ses processus de développement.
Pour les auteurs du rapport, les efforts annoncés par Huawei ne semblent pas véritablement porter de fruits. Des vulnérabilités continuent d’être signalées, en nombre ; « certaines vulnérabilités sérieuses rapportées dans les évaluations précédentes continuent de persister dans les versions plus récentes » ; et « le caractère des vulnérabilités n’a pas changé significativement au fil des ans ».
Des exigences trop élevées ?
Mais si le rapport du centre d’évaluation de la sécurité de Huawei peut donner l’impression d’étriller le constructeur, c’est peut-être parce qu’il ne se penche que sur celui-ci. Matthew Green, qui enseigne la cryptographie à l’université John Hopkins aux Etats-Unis, souligne ainsi que la double question de la maîtrise du code et des processus de compilation « peut être potentiellement vrai pour d’autres, en particulier ceux qui se lancent à peine et s’appuient sur une base de code immature ».
Las, pour Matthew Green, de tels acteurs n’ont pas des objectifs aussi ambitieux que ce partenariat entre Huawei et le gouvernement britannique, à savoir : « faire d’un partenaire dans lequel la confiance n’est pas totale en un partenaire de confiance ». Mais l’expert va plus loin : « personnellement, je pense que c’est un problème insolvable, même dans le meilleur des cas. Nos meilleures techniques de sécurité logicielle sont à peine suffisantes pour stopper l’introduction accidentelle de vulnérabilités par des développeurs honnêtes ».
Stephen Bellovin, chercheur en sécurité et réseaux renommé, souligne au passage la complexité des logiciels embarqués dans les équipements destinés aux opérateurs télécoms, au point qu’il est « sérieusement difficile de faire ça bien », et qu'il n'est pas plus simple d’auditer, « même avec un bon environnement de développement ». Et accessoirement, l’existence même d’un projet tel que Reproductible Builds, montre que la question de la compilation déterministe n’est pas triviale.