Matrix est un protocole de messagerie instantanée ouvert. Il est conçu pour permettre aux utilisateurs de communiquer via le chat en ligne, la voix sur IP et le chat vidéo.
Récemment le développeurs de plateformes communications décentraliséess « Matrix » a publié un avertissement sur diverses vulnérabilités qui ont été détectés et ils sont critiques dans les bibliothèques matrix-js-sdk, matrix-ios-sdk et matrix-android-sdk2 qui permettent aux administrateurs de serveur de se faire passer pour d'autres utilisateurs et de lire les messages des discussions chiffrées de bout en bout (E2EE).
Il est mentionné que pour mener à bien une attaque, un serveur domestique contrôlé par les attaquants doit être accessible (serveur domestique : un serveur pour stocker l'historique et les comptes des clients). L'utilisation du chiffrement de bout en bout côté client ne permet pas à l'administrateur du serveur d'intervenir dans la messagerie, mais les vulnérabilités identifiées permettent de contourner cette protection.
Les problèmes affectent le client principal Element Matrix (anciennement Riot) pour le Web, les ordinateurs de bureau, iOS et Android, ainsi que les applications clientes tierces telles que Cinny, Beeper, SchildiChat, Circuli et Synod.im.
Les vulnérabilités n'apparaissent pas dans les bibliothèques matrix-rust-sdk, Hydrogen-sdk, Matrix Dart SDK, Mautrix-python, Mautrix-go et Matrix-nio, ainsi que Hydrogen, ElementX, Nheko, FluffyChat, Siphon, Timmy, Applications Gomuks et Pantalaimon.
Notez que les problèmes de gravité critique sont des problèmes de mise en œuvre dans matrix-js-sdk et ses dérivés, et non des problèmes de protocole dans Matrix. La dernière version de l'article des chercheurs que nous avons vu décrit à tort Element comme "le client Matrix de référence" et confond les erreurs d'implémentation de gravité plus élevée avec des critiques de protocole de gravité inférieure.
Il existe trois scénarios attaque principale :
- L'administrateur du serveur Matrix peut casser la vérification basée sur les emoji (SAS, chaînes d'authentification courtes) en utilisant des signatures croisées et en se faisant passer pour un autre utilisateur. Le problème est causé par une vulnérabilité (CVE-2022-39250) dans le code matrix-js-sdk liée à la combinaison de la gestion de l'ID de l'appareil et des clés de signature croisée.
- Un attaquant qui contrôle le serveur peut usurper l'identité d'un expéditeur de confiance et transmettre une fausse clé pour intercepter les messages d'autres utilisateurs. Le problème est dû à une vulnérabilité dans matrix-js-sdk (CVE-2022-39251), matrix-ios-sdk (CVE-2022-39255) et matrix-android-sdk2 (CVE-2022-39248), qui a causé Le client accepte de manière incorrecte les messages adressés aux appareils chiffrés utilisant le protocole Megolm au lieu de Olm , attribuant les messages à l'expéditeur Megolm au lieu de l'expéditeur réel.
- En exploitant les vulnérabilités mentionnées dans le paragraphe précédent, l'administrateur du serveur peut également ajouter une clé de rechange factice au compte utilisateur pour extraire les clés utilisées pour chiffrer les messages.
Les chercheurs qui ont identifié la vulnérabilité a également démontré des attaques qui ajoutent un utilisateur tiers à un chat ou connecter un appareil tiers à l'utilisateur. Les attaques sont basées sur le fait que les messages de service utilisés pour ajouter des utilisateurs au chat ne sont pas liés aux clés du créateur du chat et peuvent être générés par l'administrateur du serveur.
Les développeurs du projet Matrix ont classé ces vulnérabilités comme mineures, car de telles manipulations ne sont pas inhérentes à Matrix et n'affectent que les clients basés sur le protocole, mais cela ne signifie pas qu'elles ne passeront pas inaperçues : si un utilisateur est remplacé, il sera affiché dans la liste des utilisateurs de chat, et une fois ajouté un appareil, un avertissement s'affichera et l'appareil sera marqué comme non vérifié (dans ce cas, immédiatement après l'ajout de l'appareil non autorisé, il commencera à recevoir les clés publiques nécessaires pour déchiffrer les messages.
Vous remarquerez que matrix-rust-sdk, Hydrogen-sdk et d'autres SDK de XNUMXe et XNUMXe génération n'ont pas été affectés par les bogues à l'origine des problèmes critiques ici. C'est précisément pourquoi nous avons travaillé pour remplacer les SDK de première génération par une implémentation propre et soigneusement écrite de Rust sous la forme de matrix-rust-sdk, complétée par un audit public indépendant en cours.
Les vulnérabilités sont causées par des bogues dans les implémentations individuelles du protocole Matrix et ce ne sont pas des problèmes du protocole lui-même. Actuellement, le projet a publié des mises à jour pour les SDK problématiques et certaines des applications clientes construites dessus.
Enfin oui vous êtes intéressé à en savoir plus, vous pouvez vérifier les détails dans le lien suivant