La chasse aux failles de Log4j se révèle particulièrement complexe

La chasse aux failles de Log4j se révèle particulièrement complexe

Les logiciels libres sont aujourd’hui omniprésents, mais la faille Log4j, qui affecte les applications d’entreprise Java, rappelle ce qui peut mal tourner dans la chaîne d’approvisionnement complexe des logiciels modernes.

Le problème de la faille qui touche Log4j (également connue sous le nom de Log4Shell) n’est pas seulement que les administrateurs doivent corriger cette faille, qui a reçu la note “critique” de 10 sur 10. La réelle difficulté réside dans le fait que les utilisateurs ne peuvent savoir si un produit ou un système est affecté par la vulnérabilité du composant.

publicité

Google a calculé qu’environ 17 000 paquets Java dans le dépôt Maven Central – le dépôt de paquets Java le plus important – contenaient la bibliothèque vulnérable log4j-core comme dépendance directe ou transitive.

Et maintenant, la société de sécurité JFrog en a trouvé davantage en identifiant des paquets supplémentaires contenant la vulnérabilité Log4j qui n’auraient pas été détectés par l’analyse des dépendances – c’est-à-dire des paquets contenant du code Log4j vulnérable dans l’artefact lui-même.

Il a constaté que, dans l’ensemble, l’inclusion directe de code Log4j dans les artefacts n’est pas aussi courante que l’utilisation de Log4j par le biais de dépendances. Cependant, cela représente tout de même des centaines de paquets – environ 400 – qui incluent directement du code Log4j, exposant ces paquets aux vulnérabilités de Log4j.

« Dans plus de la moitié des cas (~65 %), le code Log4j est inclus directement en tant que classes (i.e. inclusion directe / shading ), contrairement à l’inclusion de fichiers .jar complets Log4j, qui est typiquement la façon dont il est présenté dans le reste des cas. Ces chiffres indiquent que les outils qui recherchent uniquement des fichiers .jar complets passeront à côté de la plupart des cas où Log4j est inclus directement », a-t-il déclaré.

Ce bug nous rappelle pourquoi Microsoft et Google investissent dans des projets visant à renforcer la sécurité des projets de logiciels open source, qui constituent l’épine dorsale de l’infrastructure Internet actuelle. Des recherches antérieures montrent que la grande majorité des failles logicielles se trouvent dans les bibliothèques logicielles ou les dépendances.

La gravité du bug signifie que les administrateurs ont tout intérêt à examiner toutes les applications Java susceptibles d’inclure du code Log4j. Microsoft a publié des outils d’analyse pour détecter les systèmes Windows et Linux vulnérables, les applications et les périphériques vulnérables, et JFrog offre une option supplémentaire.

JFrog met l’accent sur le fait que son analyse vise le code complémentaire plutôt que le simple fait de détecter la présence d’une version de la bibliothèque logicielle.

« La raison pour laquelle l’analyse de la liste complète des dépendances peut manquer des instances du code Log4j inclus est que les dépendances ne spécifient que les paquets externes nécessaires pour construire ou exécuter l’artefact actuel. Si le code vulnérable est inséré directement dans la base de code, il ne s’agit pas d’une dépendance. Par conséquent, pour une détection plus précise du code Log4j vulnérable, nous devons inspecter le code lui-même », indique l’entreprise dans un billet de blog.

Ces recherches mettent en évidence la vulnérabilité des systèmes informatiques actuels aux attaques visant la chaîne d’approvisionnement en logiciels.

L’importance du langage de programmation Java ne doit pas être sous-estimée. Il reste l’un des langages les plus utilisés au monde et est le langage de référence pour les entreprises. Son écosystème comprend des projets tels que la mise en œuvre d’OpenJDK par Microsoft. Microsoft utilise Java dans Azure, SQL Server, Yammer, Minecraft et LinkedIn.

Source : ZDNet.com;

Leave a Reply

Your email address will not be published. Required fields are marked *