18 avril 2024

Logiciel libre et vulnérabilités : comment assurer la sécurité de vos outils internes ?

Logiciel libre

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 :

 

security policy

 

 

 

 

 

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.

vulnérabilités

 

 

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 ?

Whaller security

 

 

 

 

 

 

 

 

 

 

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

Cyril Bras, Directeur cybersécurité de Whaller et VP Hexatrust

 

 

📖 En savoir plus : Cybersécurité

 

0 commentaires

Soumettre un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Articles recommandés