Top 10 des vulnérabilités de sécurité Java divulguées [2019 - Liste]

Nos amis d’OverOps publient chaque année un article de blog qui classe les bibliothèques Java selon leur popularité, en fonction des mentions sur GitHub. Dans cet article, nous examinons donc les vulnérabilités découvertes dans les dix principales bibliothèques Java sélectionnées par OverOps et nous nous penchons plus en détail sur trois d’entre elles. Voici tout d’abord les dix choix d’OverOps, classés par popularité :

1. Jackson

2. Hadoop

3. org.junit

4. org.junit.runner

5. org.springframework

6. Jetty

7. com.amazonaws.services

8. org.apache.http.client

9. org.apache.shiro

10. org.apache.commons.lang3

Selon notre base de données des vulnérabilités Snyk, 162 vulnérabilités ont été divulguées au total dans ces dix principales bibliothèques au cours de leur existence. Nous allons examiner plus en détail les bibliothèques Jackson, Spring Framework et Jetty afin de voir comment leurs vulnérabilités se répartissent selon les versions. Nous nous pencherons également sur leur gravité et sur les types de vulnérabilités présentes dans chacune d’elles. Ces trois exemples sont particulièrement intéressants, car ils comptent parmi les bibliothèques clés bien connues qui ont fait l’objet des divulgations de sécurité les plus importantes et que de nombreuses applications utilisent en production.

Si Snyk surveille vos projets Java, vous avez déjà été informé des vulnérabilités détectées par ses analyses. Si ce n’est pas le cas, effectuez gratuitement un test pour vérifier si votre application est concernée par l’une des vulnérabilités mentionnées dans cet article en analysant le dépôt de code de votre application avec Snyk.

Vulnérabilités de Jackson

La liste des principales bibliothèques de 2018 a légèrement changé par rapport à l’année précédente, et Jackson s’est hissé en tête cette fois-ci. Jackson est un package de traitement des données très répandu, souvent utilisé pour analyser le JSON dans les applications Java.

Au cours de son existence, cette bibliothèque a connu 21 vulnérabilités au total, dont la majorité concerne la désérialisation de données non fiables.

La désérialisation consiste à recevoir des fichiers, comme des fichiers JSON ou XML, puis à les convertir en un package que l’application hôte peut accepter. Une vulnérabilité de désérialisation de données non fiables (CWE-502) se produit lorsque l’application désérialise des données provenant d’une source non fiable sans vérifier suffisamment leur validité, ce qui permet à un attaquant de contrôler l’état ou le flux d’exécution.

Les problèmes de désérialisation Java sont connus depuis des années. Toutefois, l’intérêt pour ce problème a fortement augmenté en 2015, lorsque des classes susceptibles d’être exploitées pour exécuter du code à distance ont été découvertes dans une bibliothèque populaire (Apache Commons Collection). Ces classes ont été utilisées dans des attaques zero-day touchant IBM WebSphere, Oracle WebLogic et de nombreux autres produits.

La désérialisation est une cible facile : n’importe quelle application peut être compromise dès lors qu’elle contient une classe vulnérable dans son chemin d’exécution et qu’elle désérialise des données non fiables. L’attaquant envoie simplement la charge utile au désérialiseur, qui exécute alors la commande.

Presque toutes les vulnérabilités de ce type sont classées comme étant de gravité élevée, car dans la plupart des cas, elles impliquent uniquement la désérialisation de données non fiables. Il s’agit de certaines des vulnérabilités les plus graves répertoriées à ce jour sur l’échelle CVSS.

Êtes-vous concerné ?

La version actuelle de Jackson, la 2.9.9, ne comporte en réalité aucune vulnérabilité connue. C’est le signe que cette bibliothèque populaire est bien maintenue : les vulnérabilités signalées sont clairement prises en charge et corrigées rapidement. Pour vérifier si vos applications Java sont concernées, testez-les gratuitement dès maintenant avec Snyk. Vous recevrez également des conseils de correction qui vous indiqueront la version la plus proche, exempte de vulnérabilités, vers laquelle effectuer la mise à niveau.

Vulnérabilités de Spring Framework

Le framework Spring est sans conteste le framework Web le plus utilisé dans les applications Java modernes, par des millions de développeurs. Il ne s’agit pas simplement d’une bibliothèque, mais d’un écosystème complet qui comprend différents composants. Compte tenu de l’ampleur de son utilisation, le nombre de vulnérabilités paraît finalement assez faible ! Au cours des décennies d’existence du framework Spring, seules 96 vulnérabilités ont été découvertes. Le graphique suivant montre leur répartition entre les différentes versions du framework, selon la version dans laquelle elles ont été identifiées :

Comme vous pouvez l’imaginer, la découverte des vulnérabilités prend du temps. Par conséquent, nombre d’entre elles sont restées dans la bibliothèque pendant plusieurs versions avant qu’un correctif ne soit mis en œuvre. Elles ont été comptabilisées une fois pour chaque version dans laquelle elles ont été découvertes ; c’est pourquoi le total des nombres ci-dessus n’est pas égal à 96. Cela explique également pourquoi le nombre de vulnérabilités diminue à mesure que l’on se rapproche de la version actuelle : il est probable que des vulnérabilités existent, mais elles n’ont pas encore été découvertes.

La plupart des vulnérabilités sont classées comme étant de gravité élevée ou moyenne, ce qui est assez courant pour une bibliothèque ou un framework offrant aux applications un large éventail de fonctionnalités, notamment la prise en charge des points de terminaison, du transport et de la sécurité.

Examinons maintenant ces vulnérabilités par type. Nous répertorions ci-dessous tous les types de vulnérabilités recensés au moins cinq fois dans l’historique du framework Spring. On observe une grande diversité de types, ce qui s’explique là encore par l’étendue du framework Spring. Il convient également de mentionner la vulnérabilité d’exécution de code arbitraire, qui découle parfois de l’exploitation du Spring Expression Language (SPEL), comme dans cet exemple de vulnérabilité d’exécution de code arbitraire, également appelée « Spring Break ».

Êtes-vous concerné ?

Par bonne pratique, vous devriez toujours effectuer la mise à niveau vers les versions les plus récentes disponibles pour votre application. Cependant, pour diverses raisons, cela n’est pas toujours fait régulièrement. Les bibliothèques et les frameworks sont souvent mis à niveau au besoin (et fréquemment), parfois pour corriger une vulnérabilité de sécurité, et il peut être difficile de suivre le rythme. Pour vérifier si vos applications Spring sont concernées, testez-les gratuitement dès maintenant avec Snyk. Vous recevrez également des conseils de correction qui vous indiqueront la version la plus proche, exempte de vulnérabilités, vers laquelle effectuer la mise à niveau.

Vulnérabilités de Jetty

Le projet Eclipse Jetty est parfois utilisé comme bibliothèque, mais probablement plus souvent comme serveur d’applications léger (notamment par le framework Spring Boot, associé au framework Spring mentionné plus haut). Jetty est également développé depuis plusieurs décennies et bénéficie d’une vaste communauté d’utilisateurs et de contributeurs. Au fil des ans, le projet Jetty a accumulé 38 vulnérabilités, dont plus de la moitié sont des problèmes cryptographiques (13) ou des divulgations d’informations (6). Là encore, de par la nature même des composants de sécurité et des fonctionnalités qu’ils fournissent, les bogues peuvent souvent entraîner des problèmes de sécurité. Voici la liste complète des types de vulnérabilités recensés plus d’une fois dans le projet Jetty.

Êtes-vous concerné ?

Pour savoir si vous êtes concerné par ces vulnérabilités, ou par toute vulnérabilité présente dans les dépendances transitives utilisées par vos dépendances, le plus simple est de les tester gratuitement dès maintenant avec Snyk. Vous recevrez également des conseils de correction qui vous indiqueront la version la plus proche, exempte de vulnérabilités, vers laquelle effectuer la mise à niveau.

Chez Snyk, nous mettons tout en œuvre pour faciliter l’analyse des projets par les développeurs, grâce à des intégrations à vos IDE préférés, à vos dépôts de code tels que GitHub, GitLab et BitBucket, à vos serveurs CI et bien plus encore. Vous pouvez effectuer des tests gratuitement. Nous espérons que vous profiterez des fonctionnalités de correction automatique pour passer à une version plus sûre. Restez en sécurité !