Jenkins, un logiciel de serveur d’automatisation open source populaire, a publié un consultatif lundi concernant une vulnérabilité critique du serveur Web Jetty qui pourrait entraîner une corruption de la mémoire et la divulgation d’informations confidentielles.

Suivi comme CVE-2019-17638, la faille a une cote CVSS de 9.4 et affecte les versions 9.4.27.v20200227 à 9.4.29.v20200521 d’Eclipse Jetty – un outil complet qui fournit un serveur HTTP Java et un conteneur Web à utiliser dans les frameworks logiciels.

« Jenkins regroupe Winstone-Jetty, un wrapper autour de Jetty, pour agir en tant que serveur HTTP et servlet lors du démarrage avec java -jar jenkins.war. C’est ainsi que Jenkins est exécuté lors de l’utilisation de l’un des programmes d’installation ou des packages, mais pas lors de l’exécution avec servlet conteneurs tels que Tomcat », lisez l’avis.

« La vulnérabilité peut permettre à des attaquants non authentifiés d’obtenir des en-têtes de réponse HTTP pouvant inclure des données sensibles destinées à un autre utilisateur. »

le défaut, qui a un impact sur Jetty et Jenkins Core, semble avoir été introduit dans la version 9.4.27 de Jetty, qui a ajouté un mécanisme pour gérer les gros en-têtes de réponse HTTP et empêcher les débordements de tampon.

« Le problème était dans le cas d’un débordement de tampon, nous avons libéré le tampon d’en-tête, mais n’avons pas annulé le champ », responsable du projet de Jetty Greg Wilkins m’a dit.

Pour gérer cela, Jetty lève une exception pour produire une erreur HTTP 431, ce qui entraîne la libération des en-têtes de réponse HTTP dans le pool de tampons deux fois, entraînant à son tour une corruption de la mémoire et la divulgation d’informations.

Ainsi, en raison de la double libération, deux threads peuvent acquérir le même tampon du pool en même temps et permettre potentiellement à une demande d’accéder à une réponse écrite par l’autre thread, qui peut inclure des identifiants de session, des informations d’authentification et d’autres informations sensibles. .

En d’autres termes, « alors que thread1 est sur le point d’utiliser le ByteBuffer pour écrire des données de réponse1, thread2 remplit le ByteBuffer avec des données de réponse2. Thread1 procède ensuite à l’écriture du tampon qui contient désormais des données de réponse2. Il en résulte client1, qui a émis request1 et attend des réponses, pour voir response2 qui pourrait contenir des données sensibles appartenant à client2. « 

Dans un cas, la corruption de mémoire a permis aux clients de se déplacer entre les sessions, ayant ainsi un accès entre comptes, car les cookies d’authentification de la réponse d’un utilisateur ont été envoyés à un autre utilisateur, permettant ainsi à l’utilisateur A de sauter dans la session de l’utilisateur B.

Une fois les implications sécuritaires révélées, la vulnérabilité a été corrigée dans Jetty 9.4.30.v20200611 publié le mois dernier. Jenkins, qui regroupe Jetty via une interface de ligne de commande appelée Winstone, a corrigé la faille dans son utilitaire dans Jenkins 2.243 et Jenkins LTS 2.235.5 publié hier.

Il est recommandé aux utilisateurs de Jenkins de mettre à jour leur logiciel vers la dernière version pour atténuer la faille de corruption de la mémoire tampon.