OpenPGP : des certificats « empoisonnés » se propagent et bloquent des installations

OpenPGP : des certificats « empoisonnés » se propagent et bloquent des installations

OpenPGP : des certificats « empoisonnés » se propagent et bloquent des installations

Les certificats de Robert J. Hansen (alias rjh) et Daniel Kahn Gillmor (dkg), deux contributeurs de haut niveau à OpenPGP, ont été « empoisonnés » via « une attaque exploitant un défaut du protocole OpenPGP lui-même », explique Hansen. Plus tard, celui de Kristian Fiskerstrand s'est ajouté à la liste.  

« Quiconque tente d'importer un certificat "empoisonné" dans une installation OpenPGP vulnérable la bloquera très probablement d'une manière difficile à déboguer ». Problème, ces certificats sont déjà sur les serveurs de clés SKS et se répandent donc au fil des importations/vérifications. 

Hansen ajoute que cette attaque ne peut pas être atténuée par les serveurs de clés SKS pour l'instant à cause de leur manière de fonctionner. Les futures versions d'OpenPGP auront certainement des mécanismes de défense, mais aucun délai n'est donné et tout le monde ne profitera certainement pas de cette mise à jour. 

Actuellement, la meilleure protection est d'arrêter de recevoir des informations des serveurs de clés SKS. Si une petite poignée de certificats sont pour le moment concernés, leur nombre ira certainement croissant selon Hansen, augmentant ainsi les risques.

Daniel Kahn Gillmor arrive à la même conclusion et propose donc les mêmes mesures de protection pour le moment : « Mon identité cryptographique publique a été spammée à un point tel qu'elle est inutilisable [...] N'actualisez pas mon certificat OpenPGP à partir du réseau de serveur de clés SKS ». Il recommande à la place d'utiliser « un serveur de clés "contraint", tel que keys.openpgp.org » et « un client de messagerie compatible avec Autocrypt ». Il donne de plus amples détails sur son blog.

Il ajoute que « SKS est connu pour être vulnérable à ce type de spams de certificats et est difficile à atténuer en raison du mécanisme de synchronisation ». Le module de chiffrement Enigmail pourrait ainsi devenir inutilisable avec un certificat « empoison » de cette manière. 

Hansen en profite enfin pour pousser un coup de gueule contre certains utilisateurs qui ne mettent jamais (ou presque) à jour leur installation : « Ils sont foutus. Tôt ou tard, ils vont importer un certificat empoisonné [...] Cela pourrait arriver demain ou dans cinq ans ».

« La prochaine version d’Enigmail n’utilisera plus le réseau SKS par défaut. Génial ! Mais qu'en est-il des utilisateurs Enigmail existants ? Ils verront une signature, cliqueront sur "Import Key", et ... bam. Ils ne vont probablement pas penser à une attaque malveillante empoisonnant les certificats. Ils vont penser "c'est de la merde" et s'en aller ».

Commentaires (12)


Si j’ai bien compris, il y a deux problèmes distincts :





  • Une vulnérabilité dans le client OpenPGP qui le fait planter si des clés spécialement mal formées sont importées

  • Une faille qui permet de remplacer des clés existantes dans les annuaires publics ?




Les clés ne peuvent pas être révoquées??








Vekin a écrit :



Si j’ai bien compris, il y a deux problèmes distincts :

Une vulnérabilité dans le client OpenPGP qui le fait planter si des clés spécialement mal formées sont importées

Une faille qui permet de remplacer des clés existantes dans les annuaires publics ?





 De ce que j’ai compris, le problème viendrait surtout du fait que les serveurs SKS acceptent que n’importe qui certifie des clés (la base du réseau de confiance, jusque là…) et que du coup certains petits malins en ait profité pour spammer les clés de Daniel Kahn Gillmor et Robert J. Hansen. D’après ce que dkg raconte sur son blog, il aurait plus de 55k certifications sur sa clé publique, ce qui fait des fichiers de clés proprement gigantesque et ça fait planter tout le système.



Je vais essayer de reformuler (pour moi), pour voir si j’ai compris : un gazier s’est amusé à faire du débordement logique sur 2 certificats, profitant du fait que rien n’est jamais effacé dans l’historique des clés PGP (ce qui est en soi un comportement assurant une certaine sécurité : de la traçabilité et de l’intégrité). Donc en rajoutant des données à profusion (des signatures) sur deux certificats majeurs (très utilisés), on arrive à faire planter les outils de vérification.



Ces certificats sont donc devenus empoisonnés au sens où si on les importe, on risque de faire planter son openPGP.



Problème #1 : comme rien ne s’efface en PGP, ces certificats pourris ne seront pas effacés, et la révocation n’empêchera(it) pas le plantage.



Problème #2 : pourrir n’importe quel certificat semble facile. On pourrait, dans le pire des cas, se retrouver avec tous nos certificats PGP inutilisables…



Moi je dis : pas cool.



<img data-src=" />


Côté pratique : le mien expire dans quelques jours …. ^^


Il est gentil le garçon, mais il a sauté la formation pédagogie …



On dirait une citation de la citée de la peur <img data-src=" />

&nbsp;



“Quiconque tente d’importer un certificat “empoisonné” dans une installation OpenPGP vulnérable la bloquera très probablement d’une manière difficile à déboguer”, problème on peut tromper mille fois mille personnes, non, on peut tromper une fois mille personnes, mais on ne peut pas tromper mille fois mille personnes. Non



« Ils sont foutus. Tôt ou tard, ils vont importer un certificat empoisonné […]» et là je compte 5, 4, 3, 2, 1 et à 0, paf ! Je lui explose la tête comme une pastèque!



«Génial ! Mais qu’en est-il des utilisateurs Enigmail existants ? Ils verront une signature, cliqueront sur “Import Key”, et … bam » et après PAF ! Pastèque. Je sais c’est un peu décousu mais moi je vous retranscris ça pèle-mêle aussi.





&nbsp;Bon du coup, on fait quoi ?


Ecoutez, laissez la police faire son travail, dès que j’aurai de plus amples informations croyez bien que vous en serez les premiers informés

<img data-src=" />








crocodudule a écrit :



Bon du coup, on fait quoi ?







Ben c’est ça la grande question. Vu qu’on peut signer un certificat mille fois, qu’on peut signer mille certificats une fois, mais qu’on peut pas signer mille certificats mille fois. Ah ben si merde.



On se replie sur du MD5 pour signer du code et nos messages ?



<img data-src=" />









Guinnness a écrit :



Ecoutez, laissez la police faire son travail, dès que j’aurai de plus amples informations croyez bien que vous en serez les premiers informés

<img data-src=" />





Vous voulez pas un whisky d’abord ?









janiko a écrit :



Ben c’est ça la grande question. Vu qu’on peut signer un certificat mille fois, qu’on peut signer mille certificats une fois, mais qu’on peut pas signer mille certificats mille fois. Ah ben si merde.



On se replie sur du MD5 pour signer du code et nos messages ?



<img data-src=" />





En soi c’est pas tellement la problématique de signer mes fichiers (y a des alternatives), mais signer, voire chiffrer mes mails en étant certains que le destinataire aura facilement l’outil pour vérifier la signature et déchiffrer.



Outlook a bien sa techno, mais le client n’est pas multiplateforme (pas linux, peut-être ios et android) et surtout gratuit du coup c’est sans intérêt.



Il faut lire l’article ici :https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f

Tout est très bien expliqué. On apprend que l’architecture SKS est programmée en OCaml : un langage bien trop peu répandu pour rendre la maintenance aisée. Et que les certificats qui permettent d’authentifier un package LINUX d’un éditeur peuvent tout à fait être empoisonnés et rendre ainsi impossible la mise à jour d’ordinateur sous ce système…



The number one use of OpenPGP today is to verify downloaded packages for Linux-based operating systems, usually using a software tool called GnuPG. If someone were to poison a vendor’s public certificate and upload it to the keyserver network, the next time a system administrator refreshed their keyring from the keyserver network the vendor’s now-poisoned certificate would be downloaded. At that point upgrades become impossible because the authenticity of downloaded packages cannot be verified. Even downloading the vendor’s certificate and re-importing it would be of no use, because GnuPG would choke trying to import the new certificate. It is not hard to imagine how motivated adversaries could employ this against a Linux-based computer network.



Traduction avechttps://www.reverso.net



La première utilisation d’OpenPGP aujourd’hui est de vérifier les paquets téléchargés pour les systèmes d’exploitation basés sur Linux, généralement en utilisant un outil logiciel appelé GnuPG. Si quelqu’un empoisonne le certificat public d’un fournisseur et le télécharge sur le réseau du serveur de clés, la prochaine fois qu’un administrateur du système rafraîchit son trousseau à partir du réseau du serveur de clés, le certificat du fournisseur maintenant empoisonné serait téléchargé. Les mises à jour deviennent alors impossibles car l’authenticité des paquets téléchargés ne peut être vérifiée. Même le téléchargement du certificat du vendeur et sa réimportation ne seraient d’aucune utilité, parce que GnuPG s’étoufferait en essayant d’importer le nouveau certificat. Il n’est pas difficile d’imaginer comment des adversaires motivés pourraient utiliser ceci contre un réseau informatique basé sur Linux.


Disasm commented 2 days ago •

edited

You can detect infected keys with this script:



https://gist.github.com/Disasm/dc44684b1f2aa76cd5fbd25ffeea7332

4E2C6E8793298290 (Tor Browser Developers) is infected.


Fermer