Sécurité Huawei Les problèmes rencontrés au Royaume-Uni démontrent la nécessité d'un codage sécurisé

Publié à l'origine dans L'âge de l'information. Il s'agit d'une version mise à jour qui corrige le positionnement de Wind River Systems en ce qui concerne le soutien continu à la sécurité de son système d'exploitation en temps réel, VxWorks.

Un récent rapport du centre d'évaluation de la cybersécurité de Huawei au Royaume-Uni a identifié des problèmes de sécurité majeurs dans les processus d'ingénierie logicielle de Huawei. Alors que la plupart des nouvelles concernant ce rapport critique se concentrent sur les problèmes non résolus de l'année précédente, le problème le plus dangereux et le plus négligé est l'absence évidente de directives et de pratiques de codage sécurisées employées par Huawei. Mais c'est un problème qui peut être résolu.

Les nouvelles concernant le géant chinois des télécommunications Huawei ne cessent d'empirer. Alors que les États-Unis ont carrément interdit à l'entreprise de travailler à l'avenir pour le gouvernement, le Royaume-Uni a mieux accepté le fait que de nombreuses failles sous-jacentes dans les appareils et le code de Huawei peuvent être corrigées. Le Royaume-Uni a créé le Huawei Cyber Security Evaluation Centre (HCSEC) en 2010 afin d'évaluer et de traiter les problèmes de sécurité des produits Huawei, et de produire un rapport annuel à ce sujet. Cette année, le rapport est particulièrement accablant.

Une grande partie de l'attention portée au rapport 2019 du HCSEC dans les médias a été liée au fait que presque aucune faille de sécurité de l'année précédente n'a été corrigée. Cela inclut l'utilisation d'une ancienne version du système d'exploitation en temps réel VxWorks de Wind River qui sera bientôt en fin de vie. Huawei a promis de résoudre ce problème (et bénéficiera d'un soutien continu de Wind River Systems), mais ce système reste un composant essentiel d'une grande partie de l'infrastructure de télécommunications du Royaume-Uni.

Un facteur critique qui semble avoir été négligé par la plupart des médias grand public concerne ce qui pourrait être un processus fondamentalement défaillant, existant dans le cadre du développement et du déploiement de nouveaux logiciels et matériels par l'entreprise. Le rapport fait état de "problèmes techniques importants" dans la manière dont Huawei gère ses méthodes d'ingénierie internes.

Examinons quelques exemples de ces problèmes techniques décrits dans le rapport. Il faut dire que l'une des meilleures choses que Huawei ait faites a été de créer des directives de codage sécurisé pour aider ses ingénieurs et ses programmeurs à déployer du nouveau code. Ces lignes directrices couvrent un large éventail de bonnes pratiques, telles que l'utilisation de versions sûres connues des fonctions et processus du système à partir de bibliothèques de confiance, et certainement pas de variantes présentant des vulnérabilités connues. C'est une bonne chose en théorie, mais une évaluation réelle d'un système de production de Huawei au Royaume-Uni a révélé que ces lignes directrices n'avaient jamais été communiquées aux programmeurs, qu'ils les avaient ignorées ou qu'elles n'avaient tout simplement pas été appliquées.

Le rapport s'est penché sur des fonctions spécifiques de traitement de la mémoire au sein d'applications publiques, en l'occurrence un ensemble de tableaux d'affichage où les utilisateurs étaient invités, en tant que fonction du programme, à ajouter des données. Étant donné que les zones d'entrée des utilisateurs ne doivent jamais être considérées comme "fiables", on s'attendait à ce que ces zones ne contiennent que du code sécurisé, conformément aux lignes directrices internes de Huawei. Plus précisément, les testeurs ont examiné l'invocation directe des fonctions de manipulation de la mémoire memcpy(), strcpy() et sprintf() dans ces systèmes de production, connues pour entraîner potentiellement de graves problèmes de sécurité tels que des débordements de mémoire tampon depuis 1988.

Il est choquant de constater qu'il y a eu 5 000 invocations directes de 17 fonctions memcpy() connues et sûres, mais aussi 600 utilisations de 12 variantes non sûres. Le rapport est à peu près le même pour les autres fonctions. Il y a eu 1 400 invocations sûres de strcpy(), mais aussi 400 mauvaises avec des vulnérabilités connues. Enfin, 2 000 utilisations sûres de sprintf() ont été trouvées, contre 200 utilisations dangereuses. S'il est positif que la plupart des utilisations de ces fonctions soient sûres, il n'en reste pas moins qu'environ 20 % de l'ensemble du code est vulnérable à des attaques connues. Il s'agit là d'une surface d'attaque considérable, qui ne prend en outre en compte que les invocations directes des trois fonctions de gestion de la mémoire, et non leur utilisation indirecte par l'intermédiaire de pointeurs de fonction. Bien que les auditeurs n'aient examiné que ces fonctions spécifiques, il est peu probable que les trois fonctions de gestion de la mémoire choisies soient les seules à poser problème.

S'il est bon que Huawei ait créé un guide des meilleures pratiques à l'intention de ses programmeurs, il est clair qu'il faut aller plus loin. C'est une étape de définir les attentes en matière de sécurité, mais elles ne sont efficaces que si ces lignes directrices sont activement suivies et connues de la cohorte de développement. Huawei pourrait faire des progrès significatifs dans l'amélioration de sa sécurité en s'engageant à former ses programmeurs de manière efficace, et en ne se contentant pas de survoler les bases sur la manière de suivre ses directives internes. Ils doivent faire un pas de plus pour montrer comment coder de manière plus sûre en général. Les programmeurs doivent être suffisamment formés sur les bons (sécurisés) et les mauvais (non sécurisés) modèles de codage et se voir confier la responsabilité de mettre en pratique ce que leur entreprise prêche, à chaque fois.

Bon nombre des problèmes de codage spécifiques décrits dans le rapport du HCSEC sont abordés et appliqués dans le cadre de la plateforme de sécurité. Secure Code Warrior qui forme les programmeurs et les équipes de cybersécurité à toujours déployer et maintenir un code sécurisé. Des concepts tels que ne jamais faire confiance à l'entrée de l'utilisateur, toujours tirer des fonctions de bibliothèques établies, assainir toutes les entrées avant de les transmettre à un serveur et beaucoup d'autres pratiques de codage sûres sont constamment démontrés dans la plate-forme. Nous examinons également des vulnérabilités très spécifiques et montrons, étape par étape, comment les éviter et les atténuer.

En plus d'une formation compétente, les entreprises comme Huawei pourraient utiliser des solutions DevSecOps. Ces solutions ajoutent un coaching en temps réel directement dans l'IDE, en utilisant des recettes de codage sécurisées qui sont adaptées aux directives de sécurité de l'entreprise, agissant comme le sous-chef du développeur dans la "cuisine" de codage pendant qu'il écrit son code. Une telle approche pourrait aider les programmeurs de Huawei, quel que soit leur niveau de compétence, à écrire un meilleur code et à reconnaître les vulnérabilités potentielles, tout en permettant aux experts en sécurité de Huawei de créer un "livre de recettes" qui adhère à leurs politiques et aide à l'exécution des commandes.

L'une des principales leçons à tirer des problèmes de Huawei devrait être que la création de directives de codage sécurisées n'a aucun sens si les programmeurs ne les connaissent pas, ou ne savent tout simplement pas comment suivre les bonnes pratiques de codage. Dans le cas présent, les lignes directrices internes relatives aux meilleures pratiques se sont révélées être le zhilaohu de Huawei, ce que l'Occident appelleraitun "tigre de papier". Il s'agissait d'un document avec beaucoup de style, mais sans substance. Pour lui donner du mordant, il faudrait disposer des bons outils pratiques et d'un véritable programme de formation, qui adopte une approche pratique et développe en permanence les connaissances et les compétences.