ClickCease Vulnérabilité dans Iconv identifiée par l'équipe de Tuxcare |tuxcare.com

Rejoignez notre populaire bulletin d'information

Rejoignez 4 500+ professionnels de Linux et de l'Open Source !

2 fois par mois. Pas de spam.

Vulnérabilité dans iconv identifiée par l'équipe TuxCare (CVE-2021-43396)

Le 9 novembre 2021 - L'équipe de relations publiques de TuxCare

Iconv est une bibliothèque utilisée pour convertir entre différents codages de caractères et fait partie d'un groupe central d'outils et de bibliothèques utilisés pour effectuer des tâches de base, appelé glibc (GNU C Library). Selon la vénérable documentation de la glibc, elle permet la conversion de caractères entre 150 jeux de caractères différents.

 

Au cours des travaux réguliers sur le service ELS (Extended Lifecycle Support) de TuxCare, où des correctifs sont créés ou rétroportés vers des distributions Linux plus anciennes qui ont dépassé leur date de fin de vie, l'équipe a identifié une vulnérabilité inconnue jusqu'alors dans un chemin de code à l'intérieur d'iconv. Mais, bien sûr, trouver le bogue n'est que la moitié du travail, donc un correctif a également été développé et soumis en amont.

Les correctifs pour les systèmes couverts par ELS sont déjà disponibles pour le déploiement.

 

 

La vulnérabilité réelle se produit lorsqu'une conversion spécifique est déclenchée ; à savoir, une conversion de l'ISO-2022-JP-3 pourrait provoquer l'émission d'un caractère NUL parasite. Cela pourrait être trivialement déclenché en passant une séquence d'échappement qui change le jeu de caractères actif. Selon le cas d'utilisation, un caractère NUL supplémentaire reçu par une application appelante pourrait entraîner une corruption des données ou un comportement incohérent.

 

Ce bogue a été introduit dans le cadre de la correction de bogue 27256, comme cette vérification :

données->__statep->__count != ASCII_set

qui a été ajouté par cette correction de bogue se comporte comme si '�', le caractère NUL, était en attente et l'émet dans la sortie.

 

Lorsqu'on lui a demandé s'il pensait que le bogue était actuellement exploitable, Nikita Popov, le membre de l'équipe à l'origine de la découverte, a déclaré : "Ce cas peut être causé par un modèle d'utilisation spécial de la glibc. C'est un peu similaire à notre bogue précédent (et il est natif de toutes les bibliothèques en raison de leur nature : une bibliothèque partagée est aussi vulnérable qu'une application hôte ayant la malchance d'utiliser un ensemble malheureux d'appels de bibliothèque dans une séquence spécifique)."

Il s'agit d'une autre contribution de TuxCare aux projets en amont et d'une autre vulnérabilité identifiée par le même membre de l'équipe, après celle identifiée dans la glibc il y a quelques semaines.

 

Conformément aux meilleures pratiques du secteur en matière de divulgation responsable des vulnérabilités, les développeurs en amont ont été informés. De plus, un correctif pour corriger le problème sous-jacent a également été soumis au dépôt de projet approprié. En raison des implications de sécurité implicites dans un problème qui peut potentiellement causer des problèmes d'intégrité des données, un CVE a été demandé et attribué, CVE-2021-43396. L'existence d'une entrée CVE devrait accélérer l'incorporation de la version corrigée dans les distributions Linux répandues.

Redhat a déjà attribué un score de base CVSS v3 de 7,5 en évaluant son impact sur RHEL 6 à 8. Le NIST a également attribué un score de 7,5, ce qui signifie que la vulnérabilité présente un risque/impact élevé. La hiérarchisation des vulnérabilités pour les opérations de correction devrait tenir compte de ces informations lors de la préparation des prochaines fenêtres de maintenance.

 

Le nombre sans cesse croissant de vulnérabilités découvertes est un aspect visible du fait que de plus en plus de chercheurs et de développeurs se penchent sur le code - le code source ouvert. Si un plus grand nombre de vulnérabilités signifie généralement plus de travail pour les équipes informatiques, le bon côté des choses est que la découverte de ces problèmes avant qu'ils ne soient réellement exploités est le meilleur résultat possible.

L'équipe TuxCare continuera son travail en s'assurant que les distributions de Linux, anciennes et nouvelles, restent sécurisées, avec un engagement fort envers les projets open source et en amont.

 

Si vous souhaitez en savoir plus sur TuxCare, son service d'assistance à long terme ou son service d'assistance Linux, vous pouvez trouver les détails ici.

 

 

[Mise à jour 11/11 - Dans un souci de transparence, le statut du CVE est contesté. Alors que le bogue a été reconnu et que le correctif résout le problème, le vecteur d'attaque nécessaire pour l'exploiter est mentionné comme étant spécifique à l'application - l'application appelant iconv devrait passer les valeurs dans un ordre spécifique - plutôt que spécifique à iconv. Vous pouvez trouver plus d'informations à ce sujet dans la description du CVE ici https://nvd.nist.gov/vuln/detail/CVE-2021-43396. Il s'agit d'un exemple du processus de révision de la soumission des bogues dans l'écosystème open source. Ce post sera mis à jour avec les développements ultérieurs si/quand ils se produisent].

 

Vous cherchez à automatiser la correction des vulnérabilités sans redémarrage du noyau, temps d'arrêt du système ou fenêtres de maintenance programmées ?

Découvrez le Live Patching avec TuxCare

Devenez rédacteur invité de TuxCare

Commencer

Courrier

Rejoindre

4,500

Professionnels de Linux et de l'Open Source
!

S'abonner à
notre lettre d'information