Vulnerabilities have been discovered in most client applications for the decentralized communication platform Matrix (CVE-2021-40823, CVE-2021-40824) that allow access to keys used for transmitting messages in end-to-end encrypted (E2EE) chats. An attacker who compromises one of the chat users can decrypt messages previously sent to that user from vulnerable client applications.
Successful exploitation requires access to the recipient's message account. Access can be obtained through account parameter leaks or by hacking the Matrix server to which the user connects. The vulnerabilities pose the greatest threat to users of encrypted chat rooms connected to Matrix servers controlled by malicious actors. Administrators of such servers servers may attempt to impersonate server users to intercept messages being sent in chats from vulnerable client applications.
The vulnerabilities are caused by logical errors in the implementations of the key reaccess mechanism offered in matrix-js-sdk < 12.4.1 (CVE-2021-40823), matrix-android-sdk2 < 1.2.2 (CVE-2021-40824), matrix-rust-sdk < 0.4.0, FamedlySDK < 0.5.0, and Nheko ≤ 0.8.2. Implementations based on the matrix-ios-sdk, matrix-nio, and libolm libraries are not vulnerable.
Accordingly, the vulnerabilities are present in all applications that borrowed the problematic code and do not directly affect the Matrix and Olm/Megolm protocols. In particular, the issue impacts the main Matrix client Element (formerly Riot) for Web, desktop systems, and Android, as well as third-party client applications and libraries, including FluffyChat, Nheko, Cinny, and SchildiChat. The issue does not appear in the official client for the iOS platform, nor in the Chatty, Hydrogen, mautrix, purple-matrix, and Syphon applications.
The vulnerabilities were identified during a security audit of the Element client. Fixes have already been released for all affected clients. Users are urgently recommended to install updates and to switch clients to offline mode until the updates are installed. There is no evidence of vulnerability exploitation prior to the release of the fix. According to the regular client logs and server Determining the fact of an attack is impossible, but since the attack requires the compromise of an account, administrators can analyze the presence of suspicious logins in the authentication logs on their servers, while users can assess the list of devices linked to their account for recent reconnections and changes in trust status.
The key sharing mechanism, which has vulnerabilities in its implementation, allows a client without decryption keys for a message to request keys from the sending device or other devices of theirs. For instance, this capability is necessary for decrypting old messages on a new user device or in case the user has lost their keys. The protocol specification dictates that by default, key requests should not be responded to and should only be sent automatically to verified devices of the same user. Unfortunately, in practical implementations, this requirement has not been met, and key request submissions were processed without adequate device identification.
Source: opennet.ru
