Si vous êtes un utilisateur d'OpenSSL, vous connaissez probablement la dernière correction de bogues de haut niveau version, qui est sortie en mars 2022.

Ce correctif nous a apporté OpenSSS 3.0.2 et 1.1.1n, mises à jour pour les deux versions actuelles entièrement prises en charge du produit.

(Il existe une version héritée, 1.0.2, mais les mises à jour de cette version ne sont disponibles que pour les clients payant pour un support premium, et compte tenu des modifications et améliorations apportées au produit depuis l'époque de 1.0.2, nous vous invitons vivement à passer à une version grand public même - peut-être surtout - si vous prévoyez de continuer à payer pour le support.)

La mise à jour de mars 2022 était un rappel essentiel qu'un code profondément enfoui avec des bogues inhabituels peut finir par être négligé pendant des années, surtout si ce code fait partie d'une fonction complexe, spécialisée et de bas niveau.

Le bogue corrigé à l'époque concernait un algorithme spécial pour calculer ce que l'on appelle racines carrées modulaires, qui sont plus compliqués à calculer que les racines carrées régulières.

Malheureusement, le code pour effectuer ce calcul, utilisant un algorithme découvert pour la première fois dans les années 1890, était maladroitement codé, écrit de manière tortueuse, mal commenté et difficile à suivre.

Cependant, étant donné qu'il ne s'agissait pas d'une partie évidente "extérieure" d'OpenSSL, et étant donné que sa réécriture aurait été une tâche ardue, nous supposons qu'il a été testé avec soin pour l'exactitude de ses réponses lorsqu'il est présenté avec des nombres bien formés, mais dont la robustesse n'a pas été testée face à une entrée improbable.

Car, face à des certificats numériques qui avaient été piégés pour produire des nombres mal formés, OpenSSL BN_mod_sqrt() La fonction pourrait être amenée à boucler indéfiniment, en essayant de se rapprocher d'une réponse qui n'existait pas.

Lorsque vous travaillez uniquement avec des nombres entiers et que vous interdisez les fractions de toutes sortes, vous constatez que de nombreux nombres n'ont pas de racines carrées modulaires, tout comme vous constatez que de nombreux nombres entiers n'ont pas de racines carrées régulières. Ainsi 7×7 = 49, donc 49 a une racine carrée qui est un nombre entier, à savoir 7. Mais il n'y a pas d'entier qui peut être multiplié par lui-même pour donner 50, ou 51, car le prochain "carré parfait" est 8×8 = 64. Vous pouvez essayer aussi longtemps que vous le souhaitez, mais vous ne trouverez jamais de réponse entière pour √51.

Jamais réellement incorrect, juste incomplet

En d'autres termes, bien que le code BigNumber d'OpenSSL (de nombreux algorithmes de chiffrement reposent sur le travail avec des nombres composés de centaines, voire de milliers de chiffres) n'ait jamais donné de mal réponse, il ne se rendait parfois pas compte qu'il n'y avait pas de réponse à trouver et restait coincé dans une boucle infinie.

Cette boucle infinie, dont on pourrait abuser pour provoquer ce qu'on appelle un Déni de service (DoS), pourrait être déclenchée si un site Web malveillant envoyait un certificat numérique piégé.

Cela signifiait, ironiquement, que les logiciels scrupuleux quant à la validation des certificats numériques pouvaient être mis à genoux via ce bogue, surnommé CVE-2022-0778, tandis que les programmes qui ne se souciaient pas du tout de la validation des certificats n'en étaient pas affectés.

Compte tenu des «moments propices à l'apprentissage» importants révélés par ce bogue, nous l'avons couvert en détail non seulement sur Naked Security, où nous avons expliqué comment écrire un meilleur style de code, mais aussi sur Sophos News, où les SophosLabs ont montré les détails sanglants de la façon dont un certificat piégé pourrait déclencher la faille, et comment déboguer le code pour comprendre le bug.

Deux autres failles de sécurité en attendant

La prochaine mise à jour d'OpenSSL était 3.0.3ou 1.1.1o pour les utilisateurs de la version précédente, qui corrigeait un bogue qui n'était pas considéré comme un défaut majeur (du moins, nous ne l'avons pas couvert sur Naked Security), principalement parce que le bogue n'était pas dans le code de la bibliothèque de chiffrement OpenSSL lui-même.

Au lieu d'affecter tous les logiciels qui s'appuyaient sur OpenSSL comme fournisseur cryptographique, CVE-2022-1292 vient d'affecter un script utilitaire, écrit en Perl, fourni avec la boîte à outils OpenSSL.

Ce script, connu sous le nom de c_rehash (court pour rehachage du répertoire de certificats) est un outil peu connu qui prend un répertoire de fichiers de certificats cryptographiques, tels que ceux gérés en tant qu'autorités de certification (CA) de confiance par Mozilla, et crée une liste de hachages de fichiers qui peuvent aider les logiciels à trouver des certificats spécifiques plus rapidement que la recherche d'un liste alphabétique des noms.

Par exemple, le répertoire des certificats CA de Mozilla ressemble à ceci…

$ ls -l /usr/share/ca-certificates/mozilla -rw-r--r-- 1 canard canard 2772 2022-06-23 05:32 ACCVRAIZ1.crt -rw-r--r-- 1 canard canard 1972 2022-06-23 05:32 AC_RAIZ_FNMT-RCM.crt -rw-r--r-- 1 canard canard 904 2022-06-23 05:32 AC_RAIZ_FNMT-RCM_SERVIDORES_SEGUROS.crt [. . .] -rw-r--r-- 1 canard canard 1302 2022-06-23 05:32 emSign_Root_CA_-_G1.crt -rw-r--r-- 1 canard canard 774 2022-06-23 05:32 vTrus_ECC_Root_CA .crt -rw-r--r-- 1 canard canard 1911 2022-06-23 05:32 vTrus_Root_CA.crt

…alors qu'OpenSSL c_rehash génère une liste de liens symboliques qui permettent de localiser des certificats individuels via des hachages basés sur le nom de l'émetteur dans le certificat lui-même, plutôt que via son nom de fichier :

lrwxrwxrwx 1 canard canard 23 2022-06-24 13:41 002c0b4f.0 -> GlobalSign_root_r46.crt lrwxrwxrwx 1 canard 45 2022-06-24 13:41 02265526.0 -> Entrust_Root_Certification_Authority _ -_ -2 1:36 2022a06 -> Staat_der_Nederlanden_EV_Root_CA.crt [. . .] lrwxrwxrwx 24 canard canard 13 41-03179-64.0 1:19 fe2022a06cd24 -> SZAFIR_ROOT_CA13.crt lrwxrwxrwx 41 canard canard 8 2-8.0-2 1:23 feffd2022 -> GlobalSign_Root_E06.crt 24 canard 13 canard lrwxrwx -41-413.0 46:1 ff49af2022f.06 -> TUBITAK_Kamu_SM_SSL_Kok_Sertifikasi_-_Surum_24.crt

Certains logiciels s'appuient sur ces "liens de hachage" pour agir comme une sorte de système de base de données de base pour l'indexation et la recherche de certificats spécifiques.

De plus, certaines distributions de système d'exploitation invoquent automatiquement le c_rehash script en arrière-plan pour maintenir à jour ces liens spéciaux.

Métacaractères du shell considérés comme nuisibles

Malheureusement, le script reposait sur Perl system() fonction (ou une commande équivalente) pour calculer les hachages de fichiers, et la system() système lance automatiquement un shell de commande, tel que Bash, pour lancer tous les sous-programmes nécessaires.

Et, comme vous le savez probablement, les shells de commande ne traitent pas toujours littéralement leurs arguments de ligne de commande, de sorte que si vous mettez des caractères spéciaux dans ces arguments, le shell les gère de manière potentiellement dangereuse.

Par exemple, la commande echo runthis imprime littéralement le texte runthis, mais la commande echo $(runthis) n'imprime pas directement les caractères $(runthis).

Au lieu de cela, le soi-disant métacommande $(runthis) veux dire substitution de commande, donc il dit, "Exécutez la commande runthis et remplacer le $(...) partie avec la sortie de cette commande quand elle est terminée » :

   # argument traité littéralement, aucun métacaractère trouvé $ echo runthis runthis # essaie d'exécuter 'runthis', mais aucune commande de ce type n'existe $ echo $(runthis) -bash: runthis: command not found # exécute deux commandes, récupère la sortie des deux $ echo $(whoami; uname -s -r) canard Linux 5.18.6

Si le risque posé par $(...) semble familier, c'est parce que c'est la vulnérabilité de la métacommande qui a été exploitée dans le récent Bogue "Follina" sous Windows. Pour en savoir plus et voir ce bogue en action, vous pouvez regarder notre webinaire enregistré. Cliquez simplement sur l'image ci-dessous. [Inscription obligatoire, l'accès est immédiat par la suite.]

Qu'est-ce qui a été corrigé ?

Les scripts qui acceptent des entrées non fiables de quelqu'un d'autre - qu'il s'agisse d'une chaîne tapée dans un formulaire Web ou d'un nom de fichier inventé fourni de l'extérieur - doivent faire très attention à ne pas laisser ces métacommandes spéciales fuir en tant qu'arguments shell lorsqu'ils s'appuient sur la commande shell pour exécuter des utilitaires externes.

Ci-dessous, vous pouvez voir le code qui a été changé de 1.1.1n à 1.1.1o:

Une commande Perl de la forme `...` (une commande entre backticks, comme `runthis`, est simplement une façon démodée d'écrire le $(runthis) substitution de commande) a été remplacé par une fonction interne dédiée appelée compute_hash qui fait plus attention aux métacaractères étranges dans la chaîne de commande construite.

Eh bien, il s'avère que les mainteneurs n'ont pas tout à fait saisi tous les endroits de ce script utilitaire où une commande externe a été exécutée sans le soin et l'attention nécessaires.

Cette semaine donc vu la sortie d'OpenSSL 3.0.4 et 1.1.1p, pour corriger une autre commande système risquée dans le c_rehash utilitaire:

Cette fois, c'était un appel au cp (copier le fichier) via la commande basée sur le shell system() fonction qui a été remplacée par une fonction interne dédiée plus sûre appelée copy_file.

Ce correctif a l'identifiant officiel CVE-2022-2068.

Comme l'avertit le changelog d'OpenSSL :

[L' c_rehash] Le script est distribué par certains systèmes d'exploitation de manière à s'exécuter automatiquement. Sur de tels systèmes d'exploitation, un attaquant pourrait exécuter des commandes arbitraires avec les privilèges du script.

Que faire?

• Mettez à jour OpenSSL dès que possible. Si vous comptez sur votre distribution Linux pour gérer une copie installée de manière centralisée, consultez le fabricant de votre distribution pour plus de détails. Si vous comptez sur votre propre version d'OpenSSL au lieu (ou en plus) d'une version à l'échelle du système, n'oubliez pas de mettre également à jour cette copie. Vous cherchez 3.0.4 or 1.1.1p. Courir openssl version pour voir quelle version vous avez.
• Envisagez de retirer le c_rehash utilitaire si vous l'utilisez. L'utilitaire tout-en-un openssl, qui est couramment utilisé pour générer et signer des certificats en premier lieu, inclut désormais une sous-commande intégrée appelée rehash faire le même travail. Essayer openssl rehash -help pour plus d'informations.
• Désinfectez vos entrées et sorties. Ne présumez jamais que l'entrée que vous recevez peut être utilisée telle quelle en toute sécurité et soyez prudent avec les données que vous transmettez en sortie à d'autres parties de votre code.
• Soyez vigilant pour les erreurs multiples lors de la révision du code pour des types de bogues spécifiques. Un programmeur qui était négligent avec un system() commande à un endroit dans le code peut avoir fait des erreurs similaires ailleurs.

Les programmeurs produisent (ou reproduisent) souvent le même type de bogue plusieurs fois, généralement pour des raisons parfaitement innocentes et compréhensibles.

Soit ils n'étaient pas au courant de cette classe de bogues au moment où ils ont travaillé sur le code, soit ils ont pris un "raccourci temporaire" pour accélérer le travail de prototype mais ne sont jamais revenus et rangés plus tard, soit ils ont copié-collé quelqu'un code défectueux d'autre et l'ont fait leur propre…