Comme annoncé la semaine dernière, le projet OpenSSL a publié hier un correctif pour deux vulnérabilités classées « gravité critique » dans la librairie cryptographique la plus utilisée au monde. En effet, les responsables du projet avaient prévenu les utilisateurs qu'ils devaient se préparer à recevoir un correctif critique le 1er novembre dernier. À la suite de tests supplémentaires, le niveau de gravité a donc été revu à la baisse. Les entreprises doivent néanmoins déterminer quelles applications et quels serveurs sont concernés et déployer les correctifs dès que possible. Les vulnérabilités affectent toutes les versions d'OpenSSL 3.0, disponible depuis l'année dernière.

Des dépassements de tampon dans la vérification des certificats X.509

Les deux vulnérabilités, référencées CVE-2022-3786 et CVE-2022-3602, permettent des dépassements de tampon dans la fonctionnalité de décodage du punycode introduite pour la première fois en septembre 2021 dans OpenSSL 3.0.0. Le punycode est un système de représentation des caractères Unicode en ASCII et il est utilisé par exemple pour représenter les noms de domaine internationalisés dans le système DNS. Dans OpenSSL, le code vulnérable sert à traiter les contraintes de noms d'adresses électroniques dans les certificats X.509, également connus sous le nom de certificats SSL/TLS. « Toute application OpenSSL 3.0 qui vérifie les certificats X.509 reçus de sources non fiables doit être considérée comme vulnérable », ont déclaré les mainteneurs d'OpenSSL dans un avis. « Cela inclut les clients TLS et les serveurs TLS configurés pour utiliser l'authentification client TLS ». 

La plupart des protocoles de communication chiffrée les plus courants, comme le HTTPS, reposent sur des clients, notamment des navigateurs ou des applications, qui vérifient l'identité des serveurs auxquels ils se connectent en validant leurs certificats. Dans un tel scénario, il faudrait qu'une application se connecte à un serveur qui présenterait un certificat malveillant pour que l'une ou l'autre de ces vulnérabilités puisse être exploitée. Un attaquant pourrait aussi forcer cette condition avec une attaque de type « man-in-the-middle » (MitM) où il serait capable de s'insérer entre l'application et le serveur et de détourner les requêtes de l'application. Dans les cas où les serveurs sont configurés pour utiliser l'authentification du client, et donc que le serveur valide également l'identité du client en vérifiant un certificat qu'il présente, les serveurs seraient également vulnérables. 

Une faille d'OpenSSL rétrogradée de critique à haute gravité

Le projet OpenSSL n'utilise pas le système de notation des vulnérabilités CVSS. Il dispose de son propre système de classement de la gravité, décrit dans sa politique de sécurité. Selon cette politique, il considère comme critique les problèmes affectant « les configurations courantes et susceptibles d'être exploitables ». Il peut s'agir, par exemple, d'une divulgation importante du contenu de la mémoire du serveur (pouvant révéler des informations sur l'utilisateur), de vulnérabilités facilement exploitables à distance pour compromettre les clés privées du serveur, ou pour lesquelles l'exécution de code à distance est considérée comme probable dans des situations courantes ». Théoriquement, les dépassements de tampon peuvent entraîner l'exécution de code à distance, mais cela dépend fortement des conditions nécessaires à leur déclenchement et des diverses mesures d'atténuation utilisées sur une plate-forme ou un système particulier. 

Initialement, les responsables considéraient la faille CVE-2022-3602 comme critique parce qu’elle permet un débordement de pile de 4 octets et la faille CVE-2022-3786 comme de haute gravité parce que l'attaquant ne peut pas contrôler le contenu de l'écrasement des données. Cependant, après de nouvelles discussions et des tests effectués en collaboration avec les entreprises qui ont été pré-notifiées sur la nature de la vulnérabilité - y compris les fournisseurs de systèmes d'exploitation à usage général qui intègrent OpenSSL, comme les distributions Linux - la gravité a été révisée. « En premier lieu, nous avons reçu des rapports indiquant que, sur certaines distributions Linux, la disposition de la pile était telle que les 4 octets écrasaient un tampon adjacent qui n'avait pas encore été utilisé et qu'il n'y avait donc pas de plantage ou de possibilité d'exécution de code à distance », indique le projet dans son avis. « Ensuite, de nombreuses plateformes modernes mettent en œuvre des protections contre les dépassements de pile qui atténueraient le risque d'exécution de code à distance et conduisent généralement à un crash » 

Cela ne signifie pas qu'il n'y a pas de situations, de configurations et de plateformes où la faille peut facilement conduire à l'exécution de code à distance. OpenSSL est distribué sous forme de code et peut fonctionner sur une grande variété de plateformes, y compris les systèmes embarqués. Les applications peuvent également l’utiliser directement en bundle et établir des liens statiques avec lui ou utiliser la bibliothèque incluse dans le système d'exploitation, si celui-ci l’inclut en bundle. Cependant, les mainteneurs ont estimé que les critères de « configurations courantes et susceptibles d'être exploitables » pouvant s’appliquer aux failles critiques n'étaient plus remplis par cette vulnérabilité. 

OpenSSL 3.0, pas encore largement adopté

Côté serveurs, l'adoption d'OpenSSL 3.0 n'est pas encore très importante. Selon Censys, une entreprise qui analyse l'ensemble de l'espace IP de l'Internet et recueille des informations sur les services en cours d'exécution, près de 1,8 million d'hôtes uniques sur Internet ont un ou plusieurs services utilisant OpenSSL. Mais seulement 7000 (0,4 %) d'entre eux environ utilisent une version d'OpenSSL supérieure ou égale à la version 3.0.0. De plus, parmi ceux qui utilisent OpenSSL 3.0, seule une fraction d’entre eux est susceptible d'effectuer une authentification côté client et d'être vulnérable. Évidemment, cette télémétrie ne concerne que les serveurs accessibles depuis lnternet et non ceux qui se trouvent sur des réseaux internes, qui pourraient également être facilement accessibles par des attaquants qui s'introduisent dans un réseau. Après analyse des réseaux de ses clients, l'entreprise de cloud et de sécurité Akamai a constaté que la moitié d'entre eux environ possédaient au moins une machine avec au moins un processus utilisant une version vulnérable d'OpenSSL. Le pourcentage de machines utilisant une version vulnérable d'OpenSSL sur ces réseaux variait de 0,2 % à 33 %, avec une médiane de 6,1 %. Comme ces vulnérabilités ont plus de chance d'être exploitées sur les clients que sur les serveurs, il est beaucoup plus difficile de déterminer l'importance de l'impact sur les applications clientes qui utilisent OpenSSL pour se connecter aux serveurs. 

On peut considérer qu'il s'agit d'une vulnérabilité transitive - c’est-à-dire de vulnérabilités héritées de dépendances logicielles tierces - pour de nombreuses applications et les entreprises peuvent avoir du mal à en assurer le suivi jusqu'à ce que des mesures, comme les nomenclatures logicielles (Software Bill of Materials, SBOM) soient plus largement adoptés dans le secteur. Heureusement, un facteur limitant important pour cet exploit est qu'il ne peut se produire qu'après la validation de l'émetteur du certificat. Cela signifie que dans la plupart des cas, si la validation des certificats est appliquée correctement, les attaquants doivent obtenir un certificat malveillant auprès d'une autorité de certification (CA) de confiance. « Alors que les bogues de débordement de mémoire peuvent conduire aux pires scénarios, les informations dont on dispose sur cette vulnérabilité particulière semblent indiquer que le niveau de difficulté d'un exploit est très élevé », a expliqué Brian Fox, directeur technique de l’entreprise de sécurité de la chaîne logistique logicielle Sonatype. « La vulnérabilité nécessite un certificat malformé de confiance ou signé par une autorité de nommage. Cela signifie que les autorités devraient être en mesure d'empêcher rapidement la création de certificats conçus pour cibler cette vulnérabilité, ce qui limite davantage la portée », a ajouté M. Fox.

Red Hat a publié un avis et diffusé des correctifs OpenSSL pour Red Hat Enterprise Linux 9. Le fournisseur évalue l'impact des failles comme important et il a déclaré que ni SELinux ni Kpatch ne les atténuaient. Les entreprises doivent immédiatement mettre à jour OpenSSL sur leurs systèmes ou dans leurs applications vers la version 3.0.7 publiée mardi. Le projet a également publié OpenSSL 1.1.1s au même moment, mais il s'agit d'une version de correction de bogue qui n'est pas liée à ces vulnérabilités. La branche OpenSSL 1.1.x n'est pas affectée et elle est toujours prise en charge jusqu'en septembre 2023, mais les responsables du projet conseillent aux développeurs d'applications de toujours utiliser la dernière version dans leurs applications, à savoir la 3.0.7 pour le moment.