Matrix.org - SecurityThe Matrix.org FoundationZola2023-08-04T10:30:00+00:00https://matrix.org/category/security/atom.xmlDisclosure: Bridges security issues2023-08-04T10:30:00+00:002023-08-04T10:30:00+00:00Integrations Team, Matrix Security Teamhttps://matrix.org/blog/2023/08/bridges-vulnerability-disclosure/<p>Hi folks. As previously mentioned on <a href="https://matrix.org/blog/2023/07/bridges-security-updates/">Monday</a>, we’re now disclosing the vulnerabilities patched for the IRC, Slack and Hookshot bridges. If you have not already done so, please ensure you are running the patched versions.</p>
<p>Today we are disclosing the 3 vulnerabilities.</p>
<h2 id="matrix-appservice-bridge-doesn-t-verify-the-sub-parameter-of-an-openid-token-exchange-cve-2023-38691">matrix-appservice-bridge doesn't verify the sub parameter of an openId token exchange (CVE-2023-38691)</h2>
<p><a href="https://github.com/matrix-org/matrix-appservice-bridge/security/advisories/GHSA-vc7j-h8xg-fv5x">GHSA-vc7j-h8xg-fv5x</a> / <a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-38691">CVE-2023-38691</a></p>
<p>The <code>POST /v1/exchange_openid</code> endpoint did not check that the servername part of the <code>sub</code> parameter (containing the user's <em>claimed</em> MXID) is the same as the servername we are talking to. This could allow a malicious actor to spin up a server on any given domain, respond with a <code>sub</code> parameter according to the user they want to act as and use the resulting token to perform provisioning requests.</p>
<p>This is now patched so that the server part of the sub / user ID is checked against the server used to make the request.</p>
<p>Discovered and reported by a community member.</p>
<h2 id="irc-command-injection-via-admin-commands-containing-newlines-cve-2023-38690">IRC command injection via admin commands containing newlines (CVE-2023-38690)</h2>
<p><a href="https://github.com/matrix-org/matrix-appservice-irc/security/advisories/GHSA-3pmj-jqqp-2mj3">GHSA-3pmj-jqqp-2mj3</a> / <a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-38690">CVE-2023-38690</a></p>
<p>When the IRC bridge attempted to parse an admin command from a Matrix user, it would only split arguments by a literal space. For example, sending “!join #matrix\nfoobar” would treat the channel name as “#matrix\nfoobar”. This could then be exploited to inject any IRC command into the bridge to be run. Since the !join command first joins via the bridge bot user, it could be used to execute commands as the bridge bot.</p>
<p>This is now patched so that both the command handler is more strict about its arguments, as well as channel names being explicitly validated when provided by users.</p>
<p>Discovered and reported by <a href="https://valentin-lorentz.fr/">Val Lorentz</a>.</p>
<h2 id="events-can-be-crafted-to-leak-parts-of-targeted-messages-from-other-bridged-rooms-cve-2023-38700">Events can be crafted to leak parts of targeted messages from other bridged rooms (CVE-2023-38700)</h2>
<p><a href="https://github.com/matrix-org/matrix-appservice-irc/security/advisories/GHSA-c7hh-3v6c-fj4q">GHSA-c7hh-3v6c-fj4q</a> / <a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-38700">CVE-2023-38700</a></p>
<p>The IRC bridge caches recent timeline messages in memory, so that when a reply is seen for a message it doesn’t need to request the event content from the homeserver. However the room ID was not validated when accessing this cache, so a malicious actor could craft a reply event in another room referencing any event ID (so long as it was still in the bridge cache) to trick the bridge into posting the message content into a bridged reply.</p>
<p>Discovered and reported by <a href="https://valentin-lorentz.fr/">Val Lorentz</a>.</p>
<p>If you have further questions, please reach out on <a href="mailto:security@matrix.org">security@matrix.org</a></p>
Bridges Security Update2023-07-31T11:40:00+00:002023-07-31T11:40:00+00:00Integrations Team, Matrix Security Teamhttps://matrix.org/blog/2023/07/bridges-security-updates/<p>Today we are announcing security updates for several of our bridges.</p>
<ul>
<li>matrix-appservice-irc <a href="https://github.com/matrix-org/matrix-appservice-irc/releases/tag/1.0.1">1.0.1</a> affected by GHSA-vc7j-h8xg-fv5x <a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-38691">CVE-2023-38691</a>, GHSA-3pmj-jqqp-2mj3 / <a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-38690">CVE-2023-38690</a>, and GHSA-c7hh-3v6c-fj4q</li>
<li>matrix-hookshot <a href="https://github.com/matrix-org/matrix-hookshot/releases/tag/4.4.1">4.4.1</a> affected by GHSA-vc7j-h8xg-fv5x / <a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-38691">CVE-2023-38691</a></li>
<li>matrix-appservice-slack <a href="https://github.com/matrix-org/matrix-appservice-slack/releases/tag/2.1.2">2.1.2</a> affected by GHSA-vc7j-h8xg-fv5x / <a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-38691">CVE-2023-38691</a></li>
</ul>
<p>In addition we have released matrix-appservice-bridge <a href="https://github.com/matrix-org/matrix-appservice-bridge/releases/tag/9.0.1">9.0.1</a> (and backported to <a href="https://github.com/matrix-org/matrix-appservice-bridge/releases/tag/8.1.2">8.1.2</a>) which patches GHSA-vc7j-h8xg-fv5x.</p>
<p>All mentioned bridges are affected by a vulnerability in the provisioning interfaces of these bridges. If you are unable to upgrade, please disable provisioning for now (which should be documented in the relevant bridge sample config). </p>
<span id="continue-reading"></span>
<ul>
<li><a href="https://github.com/matrix-org/matrix-appservice-irc/blob/develop/config.sample.yaml#L520-L522">IRC bridge config</a>
<ul>
<li>Set <code>provisioning.enabled</code> to false.</li>
</ul>
</li>
<li><a href="https://github.com/matrix-org/matrix-appservice-slack/blob/a9f555308fb7485ebb1df98e6c327808915f816f/config/config.sample.yaml#L163">Slack bridge config</a>
<ul>
<li>Set <code>provisioning.enabled</code> to false.</li>
</ul>
</li>
<li><a href="https://github.com/matrix-org/matrix-hookshot/blob/main/config.sample.yml#L192">Hookshot config</a>
<ul>
<li>Remove the <code>widgets</code> resource (NOT provisioning)</li>
</ul>
</li>
</ul>
<p>The IRC bridge is also affected by two additional vulnerabilities. In this case, we would recommend upgrading <strong>immediately</strong> rather than working around the problems.</p>
<p>Disclosures for these vulnerabilities, as well as CVE numbers will be out in three days (Thursday 3rd).</p>
<p><strong>We advise to upgrade as soon as possible.</strong></p>
<p>If you have further questions, please reach out on <a href="mailto:security@matrix.org">security@matrix.org</a></p>
Postponing the Libera.Chat deportalling2023-07-28T14:00:00+00:002023-07-28T14:00:00+00:00Thibhttps://matrix.org/blog/2023/07/postponing-libera-chat-deportalling/<p>We have recently announced that <a href="https://matrix.org/blog/2023/07/deportalling-libera-chat/">we will be honouring Libera Chat’s request</a> to turn off portalled rooms on the Libera.Chat bridge maintained by the Matrix.org Foundation. The changes were originally scheduled to be effective on 31st July. In the meantime, we posted <a href="https://matrix.org/blog/2023/07/make-sure-libera-bridge-keeps-working/">instructions for people to turn their portalled rooms into plumbed ones</a> so the bridge keeps working for them.</p>
<p>Some stability issues on the bridge have prevented people from turning their portalled rooms into plumbed ones. We have been actively working on resolving those issues since the first reports and the situation is gradually improving. However, at this point, we do not believe the plumbed mode can be considered sufficiently stable yet. </p>
<span id="continue-reading"></span>
<p>Additionally, as part of the project we have been made aware of several new bridge security issues. These issues must be patched ahead of the plumbing stability work thereby increasing the overall scope of the project. The limited resources of the<a href="http://Matrix.org"> Matrix.org</a> Foundation didn’t allow us to meet the deadline in time.</p>
<p>Rather than plough ahead with the original timeline and risking splitting communities, we have asked Libera Chat for an extension for turning off portal rooms to ensure successful migrations in order to make sure the bridge is ready to handle the traffic in plumbed rooms and to leave people enough time to migrate their rooms after the stabilisation work. We have asked the Libera Chat staff to allow us to postpone the deportalling to Friday 11 August, which they accepted. We’re grateful to the Libera Chat team for accommodating us.</p>
<p>We will turn off the new portal creation on Monday 31 July, but will leave the existing portals active. On Friday 11 August we will make all the portal rooms read-only, and will send a message in each portalled room to list all the public rooms plumbed to the same channel on IRC.</p>
<h2 id="security-release-information">Security release information</h2>
<p>On Monday 31st, we will release new security updates for several bridges and the matrix-appservice-bridge library, including the IRC bridge. These will be:</p>
<ul>
<li>matrix-appservice-bridge 9.0.1</li>
<li>matrix-appservice-irc 1.0.1</li>
<li>matrix-appservice-slack 2.1.2</li>
<li>matrix-hookshot 4.4.1</li>
</ul>
<p>We, and the community, have found several vulnerabilities classified as High severity and strongly recommend upgrading as soon as possible after the release.</p>
<p>A full disclosure of the vulnerabilities will be out 3 days after the release, to allow people time to upgrade.</p>
Disclosing Synapse security advisories2023-05-24T13:44:36+00:002023-05-24T13:36:50+00:00Denis Kasakhttps://matrix.org/blog/2023/05/24/disclosing-synapse-security-advisories/<p>Today we are retroactively publishing advisories for security bugs in <a href="https://github.com/matrix-org/synapse/">Synapse</a>. From oldest to most recent, they are:</p>
<ul>
<li><a href="https://github.com/matrix-org/synapse/security/advisories/GHSA-p9qp-c452-f9r7">GHSA-p9qp-c452-f9r7</a> (<a href="https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=CVE-2022-39374">CVE-2022-39374</a>), fixed in Synapse 1.68.0 and affecting all prior versions since Synapse 1.62.0;</li>
<li><a href="https://github.com/matrix-org/synapse/security/advisories/GHSA-45cj-f97f-ggwv">GHSA-45cj-f97f-ggwv</a> (<a href="https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=CVE-2022-39335">CVE-2022-39335</a>), fixed in Synapse 1.69.0 and affecting all prior versions; and finally</li>
<li><a href="https://github.com/matrix-org/synapse/security/advisories/GHSA-f3wc-3vxv-xmvr">GHSA-f3wc-3vxv-xmvr</a> (<a href="https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=CVE-2023-32323">CVE-2023-32323</a>), fixed in Synapse 1.74.0 and affecting all prior versions.</li>
</ul>
<p>We strongly advise Synapse operators who are still on earlier Synapse versions to upgrade to the latest version (<a href="https://github.com/matrix-org/synapse/releases/tag/v1.84.0">v1.84.0</a>) or at the very least v1.74.0 (<a href="https://github.com/matrix-org/synapse/releases/tag/v1.74.0">released Dec 2022</a>), to prevent attacks based on these vulnerabilities. Please see the advisories for the full details, including a description of</p>
<ul>
<li>the vulnerability and potential attacks,</li>
<li>exactly which deployments are vulnerable, and</li>
<li>workarounds and mitigations.</li>
</ul>
<p>Because these bugs are either related to or exploitable over Matrix federation, we have delayed publishing these advisories until now out of caution. This allowed us to ensure that the majority of Synapse homeservers across the public federation have upgraded to a sufficiently patched version, based on the (opt-in) <a href="https://matrix-org.github.io/synapse/latest/usage/administration/monitoring/reporting_homeserver_usage_statistics.html">stats reporting</a> to the Matrix.org foundation.</p>
<p>If you have any questions or comments about this announcement or any of the advisories, e-mail us at <a href="mailto:security@matrix.org">security@matrix.org</a>.</p>
Security releases: matrix-js-sdk 24.0.0 and matrix-react-sdk 3.69.02023-03-28T00:00:00+00:002023-03-28T00:00:00+00:00Denis Kasakhttps://matrix.org/blog/2023/03/28/security-releases-matrix-js-sdk-24-0-0-and-matrix-react-sdk-3-69-0/<p>Today we are issuing security releases of matrix-js-sdk and matrix-react-sdk to
patch a pair of High severity vulnerabilities
(<a href="https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=CVE-2023-28427">CVE-2023-28427</a>
/ <a href="https://github.com/matrix-org/matrix-js-sdk/security/advisories/GHSA-mwq8-fjpf-c2gr">GHSA-mwq8-fjpf-c2gr</a>
for matrix-js-sdk and
<a href="https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=CVE-2023-28103">CVE-2023-28103</a>
/ <a href="https://github.com/matrix-org/matrix-react-sdk/security/advisories/GHSA-6g43-88cp-w5gv">GHSA-6g43-88cp-w5gv</a>
for matrix-react-sdk).</p>
<p>Affected clients include those which depend on the affected libraries, such as
Element Web/Desktop and Cinny. Releases of the affected clients should follow
shortly. We advise users of those clients to upgrade at their earliest
convenience.</p>
<p>The issues involve prototype pollution via events containing special strings in
key locations, which can temporarily disrupt normal functioning of
matrix-js-sdk and matrix-react-sdk, potentially impacting the consumer's
ability to process data safely.</p>
<p>Although we have only demonstrated a denial-of-service-style impact, we cannot
completely rule out the possibility of a more severe impact due to the
relatively extensive attack surface. We have therefore classified this as High
severity and strongly recommend upgrading as a precautionary measure.</p>
<p>We found these issues during a codebase audit that we had <a href="https://matrix.org/blog/2022/08/31/security-releases-matrix-js-sdk-19-4-0-and-matrix-react-sdk-3-53-0">previously
announced</a>
in an earlier security release of matrix-js-sdk and matrix-react-sdk. The
earlier release had already addressed a set of similar vulnerabilities that
were assigned
<a href="https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=CVE%2D2022%2D36059">CVE-2022-36059</a>
/ <a href="https://github.com/matrix-org/matrix-js-sdk/security/advisories/GHSA-rfv9-x7hh-xc32">GHSA-rfv9-x7hh-xc32</a>
and
<a href="https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=CVE%2D2022%2D36060">CVE-2022-36060</a>
/ <a href="https://github.com/matrix-org/matrix-react-sdk/security/advisories/GHSA-2x9c-qwgf-94xr">GHSA-2x9c-qwgf-94xr</a>,
which we had initially decided not to disclose until the completion of the
audit. Now that the audit is finished, we are disclosing those previous
advisories as well.</p>
Upgrade now to address E2EE vulnerabilities in matrix-js-sdk, matrix-ios-sdk and matrix-android-sdk22022-09-28T17:41:33+00:002022-09-28T17:41:33+00:00Matthew Hodgson, Denis Kasak, Matrix Cryptography Team, Matrix Security Teamhttps://matrix.org/blog/2022/09/28/upgrade-now-to-address-encryption-vulns-in-matrix-sdks-and-clients/<p><strong>TL;DR:</strong></p>
<ul>
<li>Two critical severity vulnerabilities in end-to-end encryption were found in
the SDKs which power Element, Beeper, Cinny, SchildiChat, Circuli, Synod.im
and any other clients based on matrix-js-sdk, matrix-ios-sdk or
matrix-android-sdk2.</li>
<li>These have now been fixed, and we have not seen evidence of them being
exploited in the wild. All of the critical vulnerabilities require
cooperation from a malicious homeserver to be exploited.</li>
<li><strong>Please upgrade immediately in order to be protected against these
vulnerabilities.</strong></li>
<li>Clients with other encryption implementations (including Hydrogen, ElementX,
Nheko, FluffyChat, Syphon, Timmy, Gomuks and Pantalaimon) are not affected;
<strong>this is not a protocol bug</strong>.</li>
<li>We take the security of our end-to-end encryption extremely seriously, and we
have an ongoing series of public independent audits booked to help guard
against future vulnerabilities. We will also be making some protocol changes
in the future to provide additional layers of protection.</li>
<li>This resolves the <a href="https://matrix.org/blog/2022/09/23/pre-disclosure-upcoming-critical-security-release-of-matrix-sd-ks-and-clients">pre-disclosure</a> issued on September 23rd.</li>
</ul>
<span id="continue-reading"></span>
<p>Hi all,</p>
<p>Recently we have been hard at work investigating some subtle security
vulnerabilities in certain implementations of Matrix's end-to-end encryption
which were responsibly disclosed to us by researchers at Royal Holloway
University London, University of Sheffield and Brave Software. Two of these
vulnerabilities are critical severity, in that they could allow malicious
server admins to attack their users, and are implementation bugs in clients
using matrix-js-sdk (e.g. Element Web) or implementations derived from
matrix-js-sdk, rather than protocol flaws. matrix-rust-sdk (and other 2nd/3rd
generation SDKs) are not affected by these. These vulnerabilities are fixed in
today's release, and we are not aware of them having been exploited in the
wild.</p>
<p><strong>If you're using Element or an application that shares the same SDKs (Beeper,
Cinny, SchildiChat, Circuli, Synod.im) then please upgrade now. Do not perform
verification with new devices until you have upgraded.</strong></p>
<p>We'd like to thank the security researchers for investing significant time and
effort into doing a deep dive to find these issues, and thus contributing
materially to making Matrix more secure for the whole ecosystem. Despite our
best efforts, there is always a risk of security issues in software, and we're
very glad to have identified and fixed these issues while also taking the
opportunity to improve our vulnerability disclosure and coordinated upgrade
process.</p>
<p>Please note that the critical severity issues are implementation issues in
matrix-js-sdk and derivatives, and are <strong>not</strong> protocol issues in Matrix. The
latest version of the researchers' paper that we've seen incorrectly presents
Element as 'the reference Matrix client', and confuses the higher severity
implementation bugs with lower severity protocol critique. This is very
unfortunate, given Hydrogen, ElementX, Nheko, FluffyChat, Syphon, Timmy, Gomuks
and Pantalaimon and other independent implementations are not affected. In
fact, every client independently implemented using the Matrix spec seems to
have got it right, which speaks well of the protocol. It's only the first
generation SDK (predating the spec) and its derivatives which had these bugs.</p>
<p>The two critical severity issues lead to three attack scenarios, all of which
are prevented by today's releases:</p>
<ul>
<li>
<p>"<em>Key/Device Identifier Confusion in SAS Verification</em>" – A bug existed in
matrix-js-sdk where it confused together device IDs and cross-signing keys
(given under the hood, cross-signing keys are represented as devices). This
could be exploited by a malicious server admin to break emoji-based
verification when cross-signing is in use, authenticating themselves rather
than the target user being verified. This bug is only present in
matrix-js-sdk (not iOS or Android SDKs), tracked as a critical severity CVE:
CVE-2022-39250.</p>
</li>
<li>
<p>"<em>Trusted Impersonation</em>" – matrix-js-sdk (and derived SDKs) suffered from
a protocol-confusion bug where it would incorrectly accept to-device messages
encrypted by Megolm rather than Olm, attributing them to the Megolm sender
rather than the actual sender. As a result, an attacker could fake the
trusted sender of to-device messages, allowing them to send fake to-device
messages to devices - e.g. fake keys to spoof historical messages from other
users. This bug is tracked as a critical severity CVE: CVE-2022-39251
(matrix-js-sdk), CVE-2022-39255 (matrix-ios-sdk) and CVE-2022-39248
(matrix-android-sdk2).</p>
</li>
<li>
<p>"<em>Malicious key backup</em>" – the above 'trusted impersonation' bug in
matrix-js-sdk (and derived SDKs) could be used by a malicious homeserver
admin to add a malicious key backup to the user's account under certain
unusual conditions in order to exfiltrate message keys. While we are not
aware of this being exploited in the wild, out of an abundance of caution we
recommend checking your key backup settings. If you are particularly paranoid
you may wish to reset your online key backup. This doesn't have a separate
CVE, as the root cause is the same as "Trusted Impersonation".</p>
</li>
</ul>
<p>Three lower priority issues were also identified by the researchers:</p>
<ul>
<li>
<p>"<em>Semi-trusted Impersonation</em>" – matrix-js-sdk (and derived SDKs) accepted keys
forwarded by other users, even if your client didn't request them. As
a result, a malicious server admin could fake an encrypted message to look as
if it was sent from a given user on that server. However, impersonated
messages like this are clearly marked by clients like Element with a clear
"The authenticity of this encrypted message can't be guaranteed" warning
– which is why we consider this low severity. That said, it's an avoidable
attack, and we've fixed this by ensuring that clients don't accept 'unsafe'
keys (with the exception of keys forwarded when you invite a user to an
existing conversation). In future, in Olm/Megolm v2 we're also linking
key-sending events to the underlying recipient Olm identity to ensure that
keys cannot be misappropriated. This issue is tracked as a moderate severity
CVE: CVE-2022-39249 (matrix-js-sdk), CVE-2022-39257 (matrix-ios-sdk) and
CVE-2022-39246 (matrix-android-sdk2).</p>
</li>
<li>
<p>"<em>Homeserver Control of Room Membership</em>" – A malicious homeserver can fake
invites on behalf of its users to invite malicious users into their
conversations, or add malicious devices into its users accounts. However,
when this happens, we clearly warn the user: if you have verified the users
you are talking to, the room and user will be shown with a big red cross to
mark if malicious devices have been added. Similarly, if an unexpected user
is invited to a conversation, all users can clearly see and take evasive
action. Therefore we consider this a low severity issue. That said, this
behaviour can be improved, and we've started work on switching our trust
model to trust-on-first-use (so that new untrusted devices are proactively
excluded from conversations, even if you haven't explicitly verified their
owner) - and we're also looking to add cryptographic signatures to membership
events in E2EE rooms to stop impersonated invites. These fixes will land
over the coming months.</p>
</li>
<li>
<p>"<em>IND-CCA break</em>" – Matrix's usage of AES-CTR to encrypt attachments, secrets
and symmetric key backups is not "IND-CCA2 secure", because it does not
include the AES initialisation vector within the hash used to secure the
payload from tampering. As a result, if an attacker could observe the result
of both a given encryption and a given decryption operation, it would be
possible to extract the encryption private key. However, this is a purely
theoretical attack as Matrix does not provide a way to mount the attack. In
the future, we will fix our use of AES-CTR to include the IV within the hash.</p>
</li>
</ul>
<p>We'd like to again thank Martin R. Albrecht and Dan Jones from the Information
Security Group at Royal Holloway University London, Benjamin Dowling from
Security of Advanced Systems Group, University of Sheffield and Sofía Celi from
Brave Software for discovering these issues and responsibly disclosing them to
us, and then working with us to agree on an extended disclosure window given
the amount of work needed to verify and ship fixes throughout Matrix over the
course of the summer period. We welcome any further formal security analysis
work, and hope that it will distinguish clearly between Matrix-the-protocol and
Matrix implementations like matrix-js-sdk, rather than conflating them. You can
read their full paper <a href="https://nebuchadnezzar-megolm.github.io/">here</a>.</p>
<p>We'd also like to thank all the downstream Element package maintainers,
downstream forks and other affected clients for working together under time
constraints for this coordinated release - your patience and understanding is
very much appreciated indeed.</p>
<p>Meanwhile, we are taking extreme measures to avoid future E2EE vulnerabilities.
You will notice that matrix-rust-sdk, hydrogen-sdk and other 2nd and 3rd
generation SDKs were not affected by the bugs at the root cause of the critical
issues here. This is <strong>precisely</strong> why we have been working on replacing the
first generation SDKs with a clean, carefully written Rust implementation in
the form of matrix-rust-sdk, complete with an ongoing independent public audit.</p>
<p>We started the process of auditing matrix-rust-sdk with the <a href="https://matrix.org/blog/2022/05/16/independent-public-audit-of-vodozemac-a-native-rust-reference-implementation-of-matrix-end-to-end-encryption">Least Authority
vodozemac audit in May</a>, and we have three more audits agreed
– covering matrix-rust-sdk-crypto, matrix-rust-sdk, and a whole reference
Matrix stack. Ironically, the mitigation work for these vulnerabilities in the
legacy SDKs has severely impacted our timelines for finishing
matrix-rust-sdk-crypto work (in fact, we had to push back the Least Authority
audit of matrix-rust-sdk-crypto given the
<a href="https://github.com/matrix-org/matrix-rust-sdk/milestone/1">burndown</a> has not
progressed), but we will be shifting to the new audited codebase as rapidly as
we possibly can.</p>
<p>Over the coming months we will also introduce our first ever major version
update of Olm and Megolm, in order to fix the MAC truncation issue highlighted
in the <a href="https://matrix.org/media/Least%20Authority%20-%20Matrix%20vodozemac%20Final%20Audit%20Report.pdf">vodozemac audit</a> (Issue J), and reduce the risk of further
key-forwarding issues (as per the "Semi-trusted Impersonation" vulnerability
above). New conversations will default to using v2 of Olm/Megolm for security,
and existing conversations can be optionally upgraded (similar to a 'room
version' upgrade in Matrix today). We are also adding extensive end-to-end
testing using <a href="https://gitlab.com/polyjuice">Polyjuice</a> and <a href="https://github.com/matrix-org/trafficlight">Traffic
Light</a> to stress-test encryption
and improve reliability.</p>
<p>Finally, we will continue our research into layering Matrix over Messaging
Layer Security (MLS) - the IETF proposed standard for interoperable end-to-end
encrypted group messaging. This work has been delayed by the mitigation
activity above, but otherwise it's making good progress and we're excited to
see how Decentralised MLS performs in reality against Olm+Megolm v2.</p>
<p>We'd like to apologise to the wider Matrix community for the inconvenience and
disruption of these issues, and thank you for your patience while we've
resolved them.</p>
<p>Matthew, Denis and the Matrix cryptography & security teams.</p>
Pre-disclosure: upcoming critical security release of Matrix SDKs and clients2022-09-23T14:53:12+00:002022-09-23T14:53:12+00:00Matrix Security Teamhttps://matrix.org/blog/2022/09/23/pre-disclosure-upcoming-critical-security-release-of-matrix-sd-ks-and-clients/<p>We will be releasing a security update to matrix-js-sdk, matrix-ios-sdk and matrix-android-sdk2 and clients which implement end-to-end encryption with these libraries, to patch <strong>critical</strong> security issues, on <strong>Wed, Sept 28th</strong>. The releases will be published in the afternoon, followed by the disclosure blog post around 16:00 UTC. The affected clients include Element Web, Desktop, iOS and Android. We will also be working with downstream packagers and forks over the coming days to ensure a synchronised release to address affected clients.</p>
<p>Clients using matrix-rust-sdk, hydrogen-sdk and matrix-nio are not affected by these critical issues. We are also auditing third-party client SDKs and clients in advance of the release, and will work with the projects if action is needed. So far we've confirmed that other popular SDK/clients including mtxclient (nheko), Matrix Dart SDK (FluffyChat), Trixnity (Timmy), Syphon, mautrix-go (Gomuks) and mautrix-python are not affected by the issues in question.</p>
<p>If you maintain or package a (potentially) affected E2EE-capable Matrix client and need to coordinate on the release, please contact <a href="mailto:security@matrix.org">security@matrix.org</a>.</p>
<p><strong>We advise to upgrade as soon as possible after the patched versions are released.</strong></p>
<p>Thank you for your patience while we work to resolve this issue.</p>
Security release of matrix-appservice-irc 0.35.0 (High severity)2022-09-13T16:56:43+00:002022-09-13T16:56:43+00:00Denis Kasakhttps://matrix.org/blog/2022/09/13/security-release-of-matrix-appservice-irc-0-35-0-high-severity/<p>We've released a new version of matrix.org's node-irc 1.3.0 and
matrix-appservice-irc 0.35.0, to patch several security issues:</p>
<ul>
<li>IRC mode operator confusion (Low, <a href="https://github.com/matrix-org/matrix-appservice-irc/security/advisories/GHSA-cq7q-5c67-w39w">GHSA-cq7q-5c67-w39w</a>)</li>
<li>Parsing issue leading to room takeovers (High, <a href="https://github.com/matrix-org/matrix-appservice-irc/security/advisories/GHSA-xvqg-mv25-rwvw">GHSA-xvqg-mv25-rwvw</a>)</li>
<li>Undisclosed issue (Moderate, <a href="https://github.com/matrix-org/matrix-appservice-irc/security/advisories/GHSA-r3p6-cg2c-c4qw">GHSA-r3p6-cg2c-c4qw</a>)</li>
</ul>
<p>The details of the final vulnerability will be released at a later date,
pending an audit of the codebase to ensure it's not affected by other similar
vulnerabilities.</p>
<p>The vulnerabilities have been patched in node-irc version 1.3.0 and
matrix-appservice-irc 0.35.0. You can get the release on
<a href="https://github.com/matrix-org/matrix-appservice-irc/releases">Github</a>.</p>
<p>The bridges running on the Libera Chat, OFTC and other networks bridged by the
Matrix.org Foundation have been patched.</p>
<p><strong>Please upgrade your IRC bridge as soon as possible.</strong></p>
<p>The above vulnerabilities were reported by <a href="https://valentin-lorentz.fr/">Val
Lorentz</a>. Thank you!</p>
Security releases: matrix-js-sdk 19.4.0 and matrix-react-sdk 3.53.02022-08-31T18:13:45+00:002022-08-31T18:13:45+00:00Denis Kasakhttps://matrix.org/blog/2022/08/31/security-releases-matrix-js-sdk-19-4-0-and-matrix-react-sdk-3-53-0/<p>Today we are issuing security releases of matrix-js-sdk and matrix-react-sdk to
patch a couple of High severity vulnerabilities (reserved as
<a href="https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=CVE%2D2022%2D36059">CVE-2022-36059</a>
for the matrix-js-sdk and
<a href="https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=CVE%2D2022%2D36060">CVE-2022-36060</a>
for the matrix-react-sdk).</p>
<p>Affected clients include those which depend on the affected libraries, such as
Element Web/Desktop and Cinny. Releases of the affected clients will follow
shortly. We advise users of those clients to upgrade at their earliest
convenience.</p>
<p>The vulnerabilities give an adversary who you share a room with the ability to
carry out a denial-of-service attack against the affected clients, making it
not show all of a user's rooms or spaces and/or causing minor temporary
corruption.</p>
<p>The full vulnerability details will be disclosed at a later date, to give
people time to upgrade and us to perform a more thorough audit of the codebase.</p>
<p>Note that while the vulnerability was to our knowledge never exploited
maliciously, some unintentional public testing has left some people affected by
the bug. We made a best effort to sanitize this to stop the breakage. If you
are affected, you may still need to clear the cache and reload your Matrix
client for it to take effect.</p>
<p>We thank <a href="https://valentin-lorentz.fr/">Val Lorentz</a> who discovered and
reported the vulnerability over the weekend.</p>
Security release: Synapse 1.61.12022-06-28T16:19:45+00:002022-06-28T16:19:45+00:00Brendan Abolivierhttps://matrix.org/blog/2022/06/28/security-release-synapse-1-61-1/<p>Hey everyone!</p>
<p>Today we're exceptionally releasing <a href="https://github.com/matrix-org/synapse/releases/tag/v1.61.1">Synapse
1.61.1</a>, which comes
as a security release. <strong>Server administrators are encouraged to update as soon as
possible.</strong></p>
<p>This release fixes a vulnerability with Synapse's URL preview feature. URL
previews of some web pages can lead to unbounded recursion, causing the request
to either fail, or in some cases crash the running Synapse process.</p>
<p>Homeservers with the <code>url_preview_enabled</code> configuration option set to <code>false</code>
(the default value) are unaffected. Instances with the <code>enable_media_repo</code>
configuration option set to <code>false</code> are also unaffected, as this also disables
the URL preview functionality.</p>
<p>Server administrators who are unable to update Synapse should disable URL
previews by setting <code>url_preview_enabled: false</code> in their configuration file.
They can also delegate URL preview to a separate, dedicated worker to ensure the
process crashing does not impact other functionality of Synapse.</p>
<p>Please see <a href="https://github.com/matrix-org/synapse/security/advisories/GHSA-22p3-qrh9-cx32">this security
advisory</a>
for more information.</p>
0.34.0 security release for matrix-appservice-irc (High severity)2022-05-04T11:02:24+00:002022-05-04T09:27:14+00:00Tadeusz Sośnierzhttps://matrix.org/blog/2022/05/04/0-34-0-security-release-for-matrix-appservice-irc-high-severity/<p>We've released updates to matrix-appservice-irc and our forked node-irc that it depends on to patch a High security vulnerability.
It's advised to update to 0.34.0 as soon as possible.</p>
<p>The vulnerability allows an attacker to manipulate a Matrix user into executing IRC commands
by having them reply to a maliciously crafted message.</p>
<p>Incorrect handling of a CR character allowed for making part of the message be sent to the IRC server verbatim
rather than as a message to the channel.</p>
<p>If you are currently a matrix-appservice-irc user, exercise caution when replying to messages from untrusted participants
in IRC bridged rooms until your bridge instance has been upgraded.</p>
<p>The vulnerability has been patched in node-irc version 1.2.1 and matrix-appservice-irc 0.34.0.
You can get the release <a href="https://github.com/matrix-org/matrix-appservice-irc/releases/tag/0.34.0">on Github</a>.</p>
<p>The bridges running on the Libera Chat, OFTC and other networks bridged by the Matrix.org Foundation have been patched.</p>
<p>The vulnerabilities are tracked as <a href="https://github.com/matrix-org/matrix-appservice-irc/security/advisories/GHSA-37hr-348p-rmf4">GHSA-37hr-348p-rmf4</a> and
<a href="https://github.com/matrix-org/node-irc/security/advisories/GHSA-52rh-5rpj-c3w6">GHSA-52rh-5rpj-c3w6</a>.</p>
<p>Thank you, <a href="https://valentin-lorentz.fr/">Val Lorentz</a> for reporting this vulnerability.</p>
High severity vulnerability in Element Desktop 1.9.6 and earlier2022-01-31T14:01:24+00:002022-01-31T14:01:24+00:00Matrix Security Teamhttps://matrix.org/blog/2022/01/31/high-severity-vulnerability-in-element-desktop-1-9-6-and-earlier/<p>Element Desktop 1.9.6 and earlier depend on a vulnerable version of Electron, leading to a <a href="https://github.com/vector-im/element-desktop/security/advisories/GHSA-mjrg-9f8r-h3m7">High severity vulnerability</a> in Element Desktop, relating to its functionality for opening downloaded files. If successfully exploited, the vulnerability allows an attacker to open an arbitrary file path on the user's machine using the platform's standard mechanisms, but without the ability to pass additional arguments or data to the program being executed.</p>
<p>However in certain platform configurations, the same vulnerability could allow an attacker to open an arbitrary URL with an arbitrary scheme instead of a file path, again using the platform's standard mechanisms. There <a href="https://positive.security/blog/url-open-rce">has been research demonstrating</a> that the ability to open arbitrary URLs can sometimes lead to arbitrary code execution.</p>
<p>The attack requires user interaction and the exploit is complex. To the best of our knowledge, the vulnerability has never been exploited in the wild.</p>
<p>Patched in 1.9.7 with further hardening done in 1.9.9 to ensure it's harder to exploit even in light of new Electron vulnerabilities. Please upgrade to 1.9.9 as soon as possible. The vulnerability has been assigned <a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-23597">CVE-2022-23597</a>.</p>
<p>Discovered and reported by <a href="https://github.com/msrkp">Sirius</a> and <a href="https://github.com/TheGrandPew">TheGrandPew</a>.</p>
On Matrix and the log4j vulnerabilities2021-12-15T12:58:02+00:002021-12-15T12:58:02+00:00Matrix Security Teamhttps://matrix.org/blog/2021/12/15/on-matrix-and-the-log4j-vulnerabilities/<p>There is currently a lot of buzz and uncertainty around a number of vulnerabilities discovered in the log4j library in the Java ecosystem. These vulnerabilities are collectively known as "Log4Shell" and currently encompass CVE-2021-44228 and CVE-2021-45046.</p>
<p>First and foremost, there are to our knowledge no Matrix homeservers written in Java. <a href="https://github.com/matrix-org/synapse/">Synapse</a>, the canonical implementation developed by the Matrix Foundation and the implementation that is backing matrix.org, is written in Python and thus unaffected. P2P Matrix relies on <a href="https://github.com/matrix-org/dendrite">Dendrite</a>, our next-gen homeserver which is written in Go and is unaffected. <a href="https://gitlab.com/famedly/conduit/">Conduit</a>, a community homeserver, is written in Rust and also unaffected. Supporting components like <a href="https://github.com/matrix-org/sygnal">Sygnal</a> and <a href="https://github.com/matrix-org/sydent">Sydent</a> are written in Python and unaffected.</p>
<p>There are two components that are commonly used in the Matrix ecosystem that do rely on Java. These are Jitsi, specifically the <a href="https://github.com/jitsi/jitsi-videobridge">Jitsi Videobridge</a> for VoIP, and <a href="https://gitlab.com/signald/signald">signald</a> used by the Signal bridge. Both components pull in log4j as part of their (transitive) dependencies. We're not aware of other bridges that are dependent on Java-based components.</p>
<p>For both of these projects updates have been published that integrate log4j 2.15.0 covering the initial CVE and we're currently waiting for additional updates to be published that integrate log4j 2.16.0 to cover the second. In the meantime, we've put all mitigations we are aware of in place on our systems and we strongly recommend everyone do the same.</p>
<p>For what mitigations to put in place, we recommend following the <a href="https://www.lunasec.io/docs/blog/log4j-zero-day-mitigation-guide/">recommendations provided by LunaSec</a>. They also provide a lot of background information on the vulnerabilities and how to audit for them.</p>
<p>Please keep an eye out for releases from the Jitsi and signald projects and follow their upgrade instructions to update your own deployments as soon as possible.</p>
Disclosure: buffer overflow in libolm and matrix-js-sdk2021-12-13T18:35:18+00:002021-12-13T16:11:07+00:00Matrix Security Teamhttps://matrix.org/blog/2021/12/13/disclosure-buffer-overflow-in-libolm-and-matrix-js-sdk/<p>Today we are releasing security updates to libolm, matrix-js-sdk, and several clients including Element Web / Desktop. Users are encouraged to upgrade as soon as possible. This resolves the <a href="https://matrix.org/blog/2021/12/03/pre-disclosure-upcoming-security-release-of-libolm-and-matrix-js-sdk">pre-disclosure</a> issued on December 3rd.</p>
<p>Fixed library versions are:</p>
<ul>
<li>libolm: <a href="https://gitlab.matrix.org/matrix-org/olm/-/tree/3.2.8">3.2.8</a></li>
<li>matrix-js-sdk: <a href="https://github.com/matrix-org/matrix-js-sdk/releases/tag/v15.2.1">15.2.1</a></li>
</ul>
<p>Client versions incorporating the fixes are:</p>
<ul>
<li>Element Web / Desktop: <a href="https://github.com/vector-im/element-web/releases/tag/v1.9.7">1.9.7</a></li>
<li>SchildiChat Web / Desktop: <a href="https://github.com/SchildiChat/schildichat-desktop/releases/tag/v1.9.7-sc.1">1.9.7-sc.1</a></li>
<li>Cinny: <a href="https://github.com/ajbura/cinny/releases/tag/v1.6.0">1.6.0</a></li>
</ul>
<p>These releases mitigate a buffer overflow in <code>olm_session_describe</code>, a libolm debugging function used by matrix-js-sdk in its end-to-end encryption (E2EE) implementation. If you rely on matrix-js-sdk for E2EE, you are affected. This vulnerability has been assigned <a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44538">CVE-2021-44538</a>.</p>
<p>Clients which do <em>not</em> use matrix-js-sdk for E2EE, like FluffyChat or Element Android / iOS, are <em>not</em> affected.</p>
<p>This issue has been present since the introduction of the <code>olm_session_describe</code> function in October 2019 (commits: <a href="https://gitlab.matrix.org/matrix-org/olm/-/commit/39a1ee0b18f0fced6d7bc293cc9a46ea70ec9e96">libolm</a>, <a href="https://github.com/matrix-org/matrix-js-sdk/commit/e6699c5424a856a639baa6d6f78d44594baaf404">matrix-js-sdk</a>).</p>
<p>We do not believe it is practical to successfully exploit this issue. However, upgrading remains important as the overflow <em>can</em> be triggered remotely.</p>
<p>Separately from the above vulnerability, we noticed during an internal audit that the libolm bindings in matrix-js-sdk were not zeroing out certain arrays containing entropy for cryptographic operations. This causes the entropy to remain resident in memory longer than necessary. As a defense-in-depth measure, this release of libolm now proactively overwrites those arrays when it is safe to do so.</p>
<p>Lastly, we are also taking this opportunity to update the version of Electron bundled with Element Desktop, pulling in the latest backported security fixes there.</p>
<p>The buffer overflow was found and reported by GitHub user <a href="https://github.com/brevilo">@brevilo</a> in the course of developing <a href="https://github.com/brevilo/jolm/">jOlm</a>, a library of Java bindings to libolm; thank you. If you believe you've discovered a security vulnerability in Matrix or its implementations, please see our <a href="https://matrix.org/security-disclosure-policy/">Security Disclosure Policy</a> for how to get in touch.</p>
Pre-disclosure: upcoming security release of libolm and matrix-js-sdk2021-12-03T00:00:00+00:002021-12-03T00:00:00+00:00Matrix Security Teamhttps://matrix.org/blog/2021/12/03/pre-disclosure-upcoming-security-release-of-libolm-and-matrix-js-sdk/<p>On <strong>Monday, 13th December</strong> we plan to publish a security release of libolm at 15:00 UTC to address a single high severity issue. To the best of our knowledge, only matrix-js-sdk and clients relying on it for E2EE are affected by this issue. This includes Element Web/Desktop and their forks (like SchildiChat). The release of libolm will be immediately followed by a security release of matrix-js-sdk and the affected clients. Users of these clients are encouraged to <strong>upgrade as soon as the patched versions are released</strong>.</p>
<p>We will be reaching out to downstream packagers to ensure they can prepare patched versions of the affected packages at the time of the release. The details of the vulnerability will be disclosed in a blog post on the day of the release. There is so far no evidence of the vulnerability being exploited in the wild.</p>
<p>The patched version numbers will be as follows:</p>
<ul>
<li>libolm 3.2.8</li>
<li>matrix-js-sdk 15.2.1</li>
<li>Element Web/Desktop 1.9.7</li>
</ul>
<p>Thank you for your patience while we work to resolve this issue.</p>
<p><em>Edit, 2021-12-13: Added patched release numbers.</em></p>