Matrix ist ein offenes Instant-Messaging-Protokoll. Es wurde entwickelt, um Benutzern die Kommunikation über Online-Chat, Voice-over-IP und Video-Chat zu ermöglichen.
Vor kurzem die Plattform-Entwickler dezentrale Kommunikations «Matrix» veröffentlichte eine Warnung vor verschiedenen Sicherheitslücken die erkannt wurden und sie sind kritisch in den Bibliotheken matrix-js-sdk, matrix-ios-sdk und matrix-android-sdk2, die es Serveradministratoren ermöglichen, sich als andere Benutzer auszugeben und Nachrichten aus Ende-zu-Ende-verschlüsselten Chats (E2EE) zu lesen.
Es wird das erwähnt Um einen Angriff erfolgreich abzuschließen, muss auf einen von den Angreifern kontrollierten Heimserver zugegriffen werden (Heimserver: ein Server zum Speichern des Clientverlaufs und der Konten). Der Einsatz von Ende-zu-Ende-Verschlüsselung auf Client-Seite erlaubt dem Server-Administrator zwar nicht, in das Messaging einzugreifen, aber die identifizierten Schwachstellen ermöglichen es, diesen Schutz zu umgehen.
Probleme betreffen den Hauptclient von Element Matrix (ehemals Riot) für Web, Desktop, iOS und Android sowie Client-Apps von Drittanbietern wie Cinny, Beeper, SchildiChat, Circuli und Synod.im.
Die Schwachstellen treten nicht in den Bibliotheken matrix-rust-sdk, hydrogen-sdk, Matrix Dart SDK, mautrix-python, mautrix-go und matrix-nio sowie Hydrogen, ElementX, Nheko, FluffyChat, Siphon, Timmy, Gomuks und Pantalaimon-Anwendungen.
Beachten Sie, dass Probleme mit dem kritischen Schweregrad Implementierungsprobleme in Matrix-js-sdk und Derivaten und keine Protokollprobleme in Matrix sind. Die neueste Version des Forschungspapiers, das wir gesehen haben, stellt Element fälschlicherweise als „den Benchmark-Matrix-Client“ dar und verwechselt Implementierungsfehler mit höherem Schweregrad mit Protokollkritik mit geringerem Schweregrad.
Es gibt drei Szenarien Hauptangriff:
- Der Matrix-Serveradministrator kann die Emoji-basierte Verifizierung (SAS, Short Authentication Chains) unterbrechen, indem er Kreuzsignaturen verwendet und sich als ein anderer Benutzer ausgibt. Das Problem wird durch eine Schwachstelle (CVE-2022-39250) im matrix-js-sdk-Code verursacht, die sich auf die Kombination von Geräte-ID-Verarbeitung und Cross-Signing-Schlüsseln bezieht.
- Ein Angreifer, der den Server kontrolliert, kann sich als vertrauenswürdiger Absender ausgeben und einen gefälschten Schlüssel weitergeben, um Nachrichten von anderen Benutzern abzufangen. Das Problem ist auf eine Schwachstelle in matrix-js-sdk (CVE-2022-39251), matrix-ios-sdk (CVE-2022-39255) und matrix-android-sdk2 (CVE-2022-39248) zurückzuführen, die verursachte Der Client akzeptiert fälschlicherweise Nachrichten, die an verschlüsselte Geräte gerichtet sind, die das Megolm-Protokoll anstelle von Olm verwenden, und schreibt die Nachrichten dem Megolm-Absender statt dem tatsächlichen Absender zu.
- Durch Ausnutzen der im vorherigen Absatz erwähnten Schwachstellen kann der Serveradministrator dem Benutzerkonto auch einen Dummy-Ersatzschlüssel hinzufügen, um die Schlüssel zu extrahieren, die zum Verschlüsseln von Nachrichten verwendet werden.
Die Forscher, die die Schwachstelle identifiziert haben demonstrierte auch Angriffe, die einen Drittbenutzer zu einem Chat hinzufügen oder ein Gerät eines Drittanbieters mit dem Benutzer verbinden. Die Angriffe basieren auf der Tatsache, dass die Dienstnachrichten, die zum Hinzufügen von Benutzern zum Chat verwendet werden, nicht mit den Schlüsseln des Chat-Erstellers verknüpft sind und vom Serveradministrator generiert werden können.
Die Entwickler des Matrix-Projekts stuften diese Schwachstellen als geringfügig ein, da solche Manipulationen Matrix nicht eigen sind und nur protokollbasierte Clients betreffen, bedeutet dies jedoch nicht, dass sie nicht unbemerkt bleiben: Wenn ein Benutzer ersetzt wird, wird er in der Liste der Chat-Benutzer angezeigt, und wenn er hinzugefügt wird ein Gerät, wird eine Warnung angezeigt und das Gerät wird als nicht verifiziert markiert (in diesem Fall beginnt es unmittelbar nach dem Hinzufügen des nicht autorisierten Geräts mit dem Empfang der öffentlichen Schlüssel, die zum Entschlüsseln von Nachrichten erforderlich sind.
Sie werden feststellen, dass matrix-rust-sdk, hydrogen-sdk und andere SDKs der XNUMX. und XNUMX. Generation nicht von den Fehlern in der Hauptursache kritischer Probleme hier betroffen waren. Genau aus diesem Grund haben wir daran gearbeitet, die SDKs der ersten Generation durch eine saubere, sorgfältig geschriebene Implementierung von Rust in Form von matrix-rust-sdk zu ersetzen, komplett mit einer laufenden unabhängigen öffentlichen Prüfung.
Schwachstellen werden durch Fehler in einzelnen Implementierungen verursacht des Matrix-Protokolls und sie sind keine Probleme des Protokolls selbst. Derzeit hat das Projekt Updates für die problematischen SDKs und einige der darauf aufbauenden Client-Anwendungen veröffentlicht.
Endlich ja Sie möchten mehr darüber erfahrenkönnen Sie die Details in der überprüfen folgenden Link