La communauté du logiciel libre met à disposition de très bons outils qui rendent de bons services, mais qui peuvent aussi être à l’origine de vulnérabilités par l’entremise des composants logiciels utilisés.
Les vulnérabilités des composants logiciels : un risque à ne pas négliger
Cyberwatch, l’outil de suivi des vulnérabilités utilisé chez Whaller
Chez Whaller, nous utilisons Cyberwatch pour assurer le suivi des vulnérabilités de nos serveurs mais également des composants logiciels pour nos usages internes. Cet outil au delà de l’OS et des vulnérabilités associées va aller creuser dans les composants logiciels installés ou dans les images Docker proposées par bon nombre de solutions en logiciel libre. Là quand on commence à creuser un peu on trouve de vieilles vulnérabilités qui sont présentes dans les images fournies et qu’il est parfois hasardeux de vouloir mettre à jour à la main sans risquer de faire planter l’appli en question.
Deux exemples de vulnérabilités critiques détectées par Cyberwatch
Aujourd’hui je décide donc de prendre le taureau par les cornes en indiquant à la communauté d’un des outils que nous utilisons en interne, les vulnérabilités les plus critiques détectées par Cyberwtach.
Je reporte donc deux CVE :
- CVE-2021-44906avec un CVSS V3 : 9.8 qui affecte Minimist <=1.2.5 et pour lequel une version 1.2.8 existe.
- CVE-2022-46175 avec un CVSS V3 : 8.8 affectant JSON5 versions antérieures à 1.0.1 et 2.2.1 corrigée dans 1.0.2, 2.2.2 et supérieures
Il s’agit donc de vulnérabilités anciennes respectivement de 2021 et 2022 avec des possibilités de corrections mais aussi des exploits disponibles ! Pour rappel, Wannacry en 2017 c’était l’exploitation de la CVE-2017-0144 publiée en mars, exploitée en mai.
La politique de signalement des vulnérabilités : une question de confiance
Regardons ce qu’indique leur politique de signalement :
L’équipe indique faire en sorte qu’il n’y ai pas de vulnérabilités connues, bon peut être n’ont ils pas contrôlé leurs dépendances.
Les limites des outils de supervision
Donc les outils de supervisions ne servent à rien ? J’entends que toutes les vulnérabilités ne sont pas toujours exploitables facilement mais à force d’en laisser des vieilles sans les corriger, il y a le risque qu’un jour une autre puisse permettre une exploitation aisée.
Je fais mon signalement, espérant avoir au moins un retour si ces vulnérabilités sont prises en considération et là finalement mon ticket est clôturé sans plus d’indications. La politesse vous connaissez ?
La sécurité du code libre : un enjeu pour toutes les entreprises
La responsabilité des communautés de développeurs
Je comprends bien évidemment que tous les outils qu’il est possible de trouver ne garantissent aucunement un niveau de sécurité mais quid des entités qui n’ont pas comme Whaller la capacité d’analyser les outils avant leur mise en service et tout au long de leur vie ?
Il n’y a pas si longtemps, une backdoor était découverte dans une librairie (https://en.wikipedia.org/wiki/XZ_Utils_backdoor) portant atteinte à la confiance dans le code libre, il est dommage que certaines communautés ne prennent pas plus en considération cette problématique.
Bref un petit coup de gueule, d’un directeur Cybersécurité agacé 🙂
Cyril Bras, Directeur cybersécurité de Whaller et VP Hexatrust
📖 En savoir plus : Cybersécurité
0 commentaires