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

Publié initialement dans Information Age. Il s'agit d'une version mise à jour qui rectifie les informations concernant le support de sécurité continu de Wind River Systems pour son système d'exploitation temps réel, VxWorks.

Un rapport récent 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. Bien qu'une grande partie de l'actualité autour de ce rapport critique se concentre sur des 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 manifeste de directives et de pratiques de codage sécurisé chez Huawei. Mais c'est un problème qui peut être résolu.

Pour le géant chinois des télécoms Huawei, la situation ne cesse de se dégrader. Alors que les États-Unis ont purement et simplement interdit à l'entreprise de travailler sur de futurs projets gouvernementaux, le Royaume-Uni a mieux accepté le fait que bon nombre des failles sous-jacentes des appareils et du code de Huawei sont réparables. Le Royaume-Uni a créé le Huawei Cyber Security Evaluation Centre (HCSEC) en 2010 pour évaluer et traiter les problèmes de sécurité des produits Huawei, et pour produire un rapport annuel à ce sujet. Cependant, le rapport de cette année est particulièrement accablant.

L'essentiel de l'attention médiatique portée au rapport 2019 du HCSEC a trait 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 temps réel VxWorks de Wind River, qui arrivera bientôt en fin de vie. Huawei a promis de résoudre ce problème (et bénéficiera d'un support continu de la part de Wind River Systems), mais il reste un composant central d'une grande partie de l'infrastructure télécom britannique.

Un facteur critique qui semble avoir été négligé par la plupart des médias grand public équivaut à ce qui pourrait être un processus fondamentalement défaillant, existant au sein du développement et du déploiement de nouveaux logiciels et matériels par l'entreprise. Le rapport note des « problèmes techniques significatifs » 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 initiatives de Huawei a été de créer des directives de codage sécurisé pour aider ses ingénieurs et programmeurs à déployer du nouveau code. Ces directives couvrent un large éventail de bonnes pratiques, comme l'utilisation de versions sûres connues de fonctions système et de processus issus de bibliothèques de confiance, et certainement pas de variantes présentant des vulnérabilités connues. C'est une excellente chose en théorie, mais une évaluation réelle d'un système de production Huawei au Royaume-Uni a révélé que ces directives n'étaient jamais communiquées aux programmeurs, ignorées par eux ou tout simplement non appliquées.

Le rapport s'est penché sur des fonctions spécifiques de gestion de la mémoire au sein d'applications publiques, en l'occurrence un ensemble de forums de discussion où les utilisateurs étaient invités, en tant que fonction du programme, à ajouter des entrées. Étant donné que les zones de saisie utilisateur ne devraient jamais être considérées comme « de confiance », il était attendu que ces zones ne contiennent que du code sécurisé, conformément aux directives internes de Huawei. Plus précisément, les testeurs ont examiné l'invocation directe des fonctions de gestion de la mémoire memcpy(), strcpy() et sprintf() au sein de ces systèmes de production, connues pour pouvoir entraîner de graves problèmes de sécurité comme le dépassement de tampon depuis 1988 .

De manière choquante, il y avait 5 000 invocations directes de 17 fonctions memcpy() sûres connues, mais aussi 600 utilisations de 12 variantes non sécurisées. Le ratio était à peu près le même pour les autres fonctions. Il y avait 1 400 invocations strcpy() sûres, mais aussi 400 mauvaises avec des vulnérabilités connues. Et 2 000 utilisations sûres de sprintf() ont été trouvées, contre 200 non sécurisées. Bien qu'il soit positif que la plupart des utilisations de ces fonctions soient sûres, cela laisse environ 20 % du code global vulnérable à des attaques connues. Il s'agit d'une surface d'attaque énorme, et cela ne prend en compte que les invocations directes des trois fonctions de gestion de la mémoire, et non les instances de leur utilisation indirecte via des 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 louable que Huawei ait créé un guide des meilleures pratiques pour ses programmeurs, il est clair qu'il faut aller plus loin. Définir les attentes en matière de sécurité est une première étape, mais elles ne sont efficaces que si ces directives sont activement suivies et connues de l'équipe de développement. Huawei pourrait faire des progrès significatifs en s'engageant à former efficacement ses programmeurs, et pas seulement en survolant les bases de leurs directives internes. Ils doivent franchir le pas supplémentaire en démontrant comment coder de manière plus sécurisée en général. Les développeurs doivent être suffisamment formés aux bons et aux mauvais modèles de codage et avoir 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 traités et appliqués dans le cadre de la plateforme 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 aux entrées utilisateur, toujours extraire des fonctions de bibliothèques établies, assainir toutes les entrées avant de les transmettre à un serveur et bien d'autres pratiques de codage sécurisé sont constamment démontrés au sein de la plateforme. 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 qualifiée, des entreprises comme Huawei pourraient utiliser des solutions DevSecOps. Cela ajoute un coaching en temps réel directement dans l'IDE, en utilisant des recettes de codage sécurisé personnalisées selon les directives de sécurité de l'entreprise, agissant comme le sous-chef du développeur dans la « cuisine » du 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 » conforme à leurs politiques.

Une leçon essentielle à tirer des difficultés de Huawei est que la création de directives de codage sécurisé ne sert à rien si les programmeurs ne les connaissent pas, ou ne savent tout simplement pas comment suivre de bonnes pratiques. Dans ce cas, les directives internes se sont révélées être le zhilaohu de Huawei ; ce que l'Occident appellerait un tigre de papier'. C'était un document avec beaucoup de style, mais sans substance. Pour lui donner du mordant, il faudrait des outils pratiques adaptés et un véritable programme de formation, axé sur la pratique et le développement continu des compétences.