Skip to main content
BlogSécuritéDigest de sécurité Linode du 1er au 7 avril 2022

Digest de sécurité Linode du 1er au 7 avril 2022

Digest de sécurité Linode

Cette semaine, nous parlerons d'une vulnérabilité de haute gravité dans le noyau Linux, d'une vulnérabilité du serveur LDAP pour Linux et d'un jour zéro dans un cadre Java populaire.

Escalade des privilèges locaux dans le noyau Linux

Un débordement de tampon du tas a été découvert dans le code de transformation IPsec ESP dans net/ipv4/esp4.c et net/ipv6/esp6.c. Selon NVD, cette faille permet à un attaquant local disposant de privilèges d'utilisateur d'écraser les objets du tas du noyau et de provoquer potentiellement une escalade locale des privilèges. La vulnérabilité est numérotée CVE-2022-27666 avec un score CVSS de base de 7.8. L'exploitation de la vulnérabilité semble être disponible sur GitHub et prétend réaliser une escalade locale des privilèges sur la dernière version de Ubuntu Desktop 21.10. Le correctif pour cette vulnérabilité a été appliqué récemment aux noyaux upstream >= 5.10 LTS.

Cause première - Le chercheur en sécurité à l'origine de l'exploit, Xiaochen Zou alias @ETenal7, déclare que "la vulnérabilité a été introduite en 2017, par le commit cac2661c53f3 et le commit 03e2a30f6a27. La logique de base de cette vulnérabilité est que le tampon de réception d'un message utilisateur dans le module esp6 est un tampon de 8 pages, mais l'expéditeur peut envoyer un message plus grand que 8 pages, ce qui crée clairement un débordement de tampon."

L'exploitation de cette vulnérabilité fait appel à diverses techniques intéressantes telles que le heap feng shui, qui consiste en une manipulation sélective de la disposition de l'espace mémoire du heap, semblable à une disposition minutieuse des entités dans l'espace dans le système chinois du feng shui. 

Authentification incorrecte dans le serveur d'annuaire 

389 Directory Server est un serveur LDAP Open Source pour Linux. Une vulnérabilité a été trouvée dans le 389 Directory Server qui permet à des mots de passe expirés d'accéder à la base de données pour provoquer une authentification incorrecte. La vulnérabilité est numérotée CVE-2022-0996 et classée CVSS 7.5 High.

Bien qu'il n'y ait pas beaucoup d'informations disponibles sur cette vulnérabilité, la mise à jour peut être installée avec le gestionnaire de paquets "dnf". Utilisez su -c 'dnf upgrade -advisory FEDORA-2022-2558f14c58' à la ligne de commande. Pour plus d'informations, consultez la documentation de dnf.

Selon le chercheur à l'origine de la démonstration de faisabilité : "Dans mes tests, je n'ai qu'un seul ACI dans la base de données qui autorise l'accès à tout utilisateur "authentifié". Après l'erreur 49 (mot de passe expiré), cette connexion devrait être considérée comme "anonyme", mais il semble qu'elle soit toujours considérée comme "authentifiée" en ce qui concerne le contrôle d'accès (ACI)."

Exécution de code à distance par un jour zéro critique dans Spring Core

Le Spring Framework est un cadre d'application et un conteneur d'inversion de contrôle pour la plate-forme Java. Les fonctionnalités de base du cadre peuvent être utilisées par n'importe quelle application Java, mais il existe des extensions pour la construction d'applications web au-dessus de la plate-forme Java EE. L'application Spring WebFlux fonctionnant avec le JDK 9+ est vulnérable à l'exécution de code à distance (RCE) et porte le numéro CVE-2022-22965.

La CVE est classée critique et plusieurs ressources de sécurité de confiance telles que LunaSec et Rapid7 ont confirmé la présence de la vulnérabilité. En raison du grand nombre de clients du framework, la vulnérabilité est comparée et nommée de la même manière que le tristement célèbre log4shell, cette fois-ci sous le nom de spring4shell. 

Bien que l'impact de la vulnérabilité soit certainement élevé puisqu'une fois exploitée, elle peut permettre l'exécution d'un code arbitraire, il existe un certain nombre de conditions requises pour qu'une implémentation soit exploitable. Pour cette raison, certains chercheurs en sécurité soutiennent que la vulnérabilité, bien qu'elle soit très grave, n'atteint pas le même niveau de difficulté que log4shell. Certaines de ces conditions sont également des risques de sécurité documentés dans la documentation de Spring, comme l'utilisation de la propriété allowfields sur le databinder.

Les autres conditions requises sont l'utilisation du framework avec Tomcat dans un déploiement WAR et l'activation de Spring beans. Cela dit, comme il s'agit d'un incident qui évolue activement, il peut y avoir différentes voies d'attaque possibles et il est donc conseillé aux clients qui sont touchés par la vulnérabilité d'effectuer une analyse approfondie de la mise en œuvre avant de prendre des mesures pour accepter/atténuer le risque de sécurité. L'article de blog de LunaSec sur le sujet fournit une explication approfondie de la vulnérabilité et peut être une ressource utile pour obtenir plus d'informations et des stratégies d'atténuation potentielles. 

Des correctifs sont désormais disponibles pour Spring4Shell dans les versions 5.3.18 et 5.2.20 de Spring.


Commentaires

Laissez un commentaire

Votre adresse électronique ne sera pas publiée. Les champs obligatoires sont marqués d'un *.