Des vulnérabilités dans GnuPG permettent de contourner la vérification et d'exécuter du code personnalisé.

Lors de la conférence 39C3 (Chaos Communication Congress) en Allemagne, douze vulnérabilités zero-day (cibles jusqu'alors inconnues et non corrigées) du kit d'outils GnuPG (GNU Privacy Guard) ont été révélées. Ce kit fournit des utilitaires compatibles OpenPGP et S/MIME pour le chiffrement des données, les signatures numériques, la gestion des clés et l'accès aux magasins de clés publics. Les vulnérabilités les plus dangereuses permettent de contourner la vérification des signatures numériques et d'exécuter du code lors du traitement de données chiffrées en représentation ASCII (ASCII Armor). Des prototypes d'exploits fonctionnels et des correctifs devraient être publiés ultérieurement. Les identifiants CVE n'ont pas encore été attribués.

Ces vulnérabilités sont dues à des erreurs dans le code de traitement et d'analyse des données, et non à des failles dans les algorithmes cryptographiques. Par exemple, une erreur d'analyse empêche de déterminer les données signées et crée des conditions dans lesquelles les données vérifiées peuvent ne pas correspondre aux données signées, permettant ainsi à un attaquant de remplacer le texte clair sans avoir accès à la clé privée.

Problèmes identifiés :

  • Un bug dans l'analyseur syntaxique des données chiffrées au format ASCII-Armor (fichiers texte contenant le bloc « BEGIN/END PGP ARMORED FILE ») provoque l'écriture en dehors des limites du tampon. Ce problème peut entraîner l'exécution de code lors du traitement de données spécialement conçues dans gpg. La vulnérabilité se manifeste dans la fonction armor_filter() et est due à une double incrémentation du compteur « n » dans la boucle « for ». Malgré la spécification de « n++ » dans la boucle elle-même, le compteur est également incrémenté dans le corps de la boucle lors de l'écriture de données dans le tampon « buf[n++] ». Par conséquent, un octet supplémentaire est écrit au-delà des limites du tampon, et la variable « ret_len » prend une valeur supérieure à sa taille réelle.
  • La possibilité de créer ou d'écraser n'importe quel fichier, dans les limites des droits d'accès actuels, résulte d'un traitement incorrect du champ « filename » dans le paquet de données. Cette vulnérabilité peut être exploitée pour exécuter du code sur le système lorsque le destinataire exécute les commandes « gpg --decrypt poc.enc » et « gpg poc.enc » pour consulter le fichier poc.enc envoyé par l'attaquant. L'exécution de code peut être réalisée, par exemple, en créant les fichiers ~/.bash_completion ou ~/.ssh/authorized_keys.
  • La possibilité de remplacer le texte clair affiché à l'utilisateur lors de la spécification de l'option « --decrypt » et de la vérification à l'aide de signatures numériques fournies séparément (signature détachée, créée avec l'option « --detach-sig » et fournie dans un fichier .sig séparé). Le problème principal est que, lors de l'envoi séparé d'un message et d'un fichier .sig, un attaquant contrôlant le trafic intermédiaire (attaque de l'homme du milieu) peut modifier le fichier .sig. La vérification restera réussie, mais lors de la consultation du message à partir du fichier .sig à l'aide de l'option « --decrypt », un contenu différent sera affiché. Exemple : `echo Plaintext > plaintext` `gpg --detach-sig plaintext` # Modification du fichier plaintext.sig par l'attaquant avec ajout de texte supplémentaire `gpg --verify plaintext.sig plaintext` # Vérifié `gpg --decrypt plaintext.sig` # Vérifié, mais texte différent affiché
  • Il est possible d'ajouter des données arbitraires à un message signé tout en conservant une vérification de signature réussie. Ce problème survient en raison de la troncature des données à la limite des 20 000 caractères lors du calcul du hachage.
  • Vérification incorrecte des codes de chiffrement authentifiés (MDC - Codes de détection de modification), qui permet la manipulation des paquets chiffrés de sorte qu'après déchiffrement, le contenu reçu soit traité comme un type de paquet différent (par exemple, perçu comme une clé publique destinée à la publication).
  • La possibilité d'insérer des données supplémentaires dans les signatures en clair créées avec l'option « --not-dash-escaped » ou converties à partir de signatures détachées peut être exploitée pour tromper l'utilisateur sur les données réellement signées. Par exemple, un utilisateur peut télécharger une clé de vérification de signature numérique valide depuis une source fiable, mais un attaquant pourrait, lors d'une attaque de type « homme du milieu » (MITM), remplacer l'image ISO téléchargée et ajouter un hachage à la signature. Ainsi, la vérification de l'image remplacée réussira si le système possède la clé de vérification correcte.
  • Substitution de données supplémentaires dans la représentation ASCII d'une signature CS (Cleartext Signature) par insertion d'un caractère de valeur zéro. Cette vulnérabilité permet, par exemple, d'insérer du texte arbitraire dans l'en-tête Hash.
  • Une interprétation erronée du format OpenPGP permet de traiter un message signé en une seule passe (encodé en ASCII) comme un message de signature en clair, moyennant une modification spécifique de son en-tête. Cette vulnérabilité permet de remplacer les données signées originales par du contenu malveillant tout en conservant l'apparence d'une vérification réussie.
  • L'absence de séparation claire entre les informations relatives au succès de la vérification de la signature numérique et le contenu du message permet la création de faux messages non signés qui semblent authentiques lors de l'exécution de « gpg --decrypt ».
  • La possibilité de créer des messages OpenPGP qui seront traités différemment par gpg par rapport à d'autres implémentations OpenPGP. Ce problème est dû à la manière dont OpenPGP gère les chaînes de caractères très longues dans la représentation ASCII des données OpenPGP.
  • Créer des conditions lors du processus de vérification de signature numérique pour revenir à l'algorithme de vérification de hachage non sécurisé SHA1.
  • La possibilité de substituer des clés secondaires (sous-clés) sans autorisation en utilisant la partie privée de la clé principale. L'attaque est menée en ajoutant un faux magasin de clés à l'aide de l'option « --keyring ».

Deux vulnérabilités supplémentaires ont été identifiées dans minisign, un outil simplifié de création et de vérification de signatures numériques. Ces deux vulnérabilités (1, 2) permettent l'utilisation de séquences d'échappement terminales (« \e[1E ») ou de caractères spéciaux (« \r ») dans le champ de commentaire afin de modifier la sortie du programme, par exemple pour remplacer les informations relatives au résultat de la vérification.

Source: opennet.ru

Achetez un hébergement fiable pour les sites avec protection DDoS, serveurs VPS VDS 🔥 Achetez un hébergement web fiable avec protection DDoS, serveurs VPS et VDS | ProHoster