Une analyse des images de micrologiciels sur les appareils de Dell, HP et Lenovo a révélé la présence de versions obsolètes de la bibliothèque cryptographique OpenSSL, soulignant un risque pour la chaîne d’approvisionnement.

Kit de développement EFI, alias EDKest une implémentation open source de l’interface micrologicielle extensible unifiée (UEFI), qui fonctionne comme une interface entre le système d’exploitation et le micrologiciel intégré au matériel de l’appareil.

L’environnement de développement du micrologiciel, qui en est à sa deuxième itération (EDK II), est livré avec son propre package cryptographique appelé CryptoPkg qui, à son tour, utilise les services du projet OpenSSL.

Selon la société de sécurité du micrologiciel Binarly, l’image du micrologiciel associée aux appareils d’entreprise Lenovo Thinkpad utilisait trois versions différentes d’OpenSSL : 0.9.8zb, 1.0.0a et 1.0.2j, dont la dernière a été publiée en 2018.

De plus, l’un des modules de micrologiciel nommé InfineonTpmUpdateDxe s’appuyait sur la version 0.9.8zb d’OpenSSL qui a été livrée le 4 août 2014.

« Le module InfineonTpmUpdateDxe est responsable de la mise à jour du firmware du Trusted Platform Module (MTP) sur la puce Infineon, » Binarly expliqué dans un article technique la semaine dernière.

« Cela indique clairement le problème de la chaîne d’approvisionnement avec les dépendances tierces lorsqu’il semble que ces dépendances n’ont jamais reçu de mise à jour, même pour des problèmes de sécurité critiques. »

Mis à part la diversité des versions d’OpenSSL, certains des progiciels de Lenovo et Dell utilisaient une version encore plus ancienne (0.9.8l), sortie le 5 novembre 2009. Le code du micrologiciel de HP utilisait également une version vieille de 10 ans. de la bibliothèque (0.9.8w).

Le fait que le micrologiciel de l’appareil utilise plusieurs versions d’OpenSSL dans le même package binaire met en évidence la façon dont les dépendances de code tiers peuvent introduire plus de complexités dans l’écosystème de la chaîne d’approvisionnement.

Binarly a en outre souligné les faiblesses de ce qu’on appelle une nomenclature logicielle (SBOM) qui résulte de l’intégration de modules binaires compilés (alias source fermée) dans le micrologiciel.

« Nous voyons un besoin urgent d’une couche supplémentaire de validation SBOM en ce qui concerne le code compilé pour valider au niveau binaire, la liste des informations de dépendance tierces qui correspondent au SBOM réel fourni par le fournisseur », a déclaré la société.

« Une approche « faire confiance mais vérifier » est le meilleur moyen de gérer les défaillances de SBOM et de réduire les risques de la chaîne d’approvisionnement. »