Security

40 posts tagged with "Security" (See all Category)

Atom Feed

Security release: Synapse 1.61.1

28.06.2022 16:19 — Releases Brendan Abolivier

Hey everyone!

Today we're exceptionally releasing Synapse 1.61.1, which comes as a security release. Server administrators are encouraged to update as soon as possible.

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.

Homeservers with the url_preview_enabled configuration option set to false (the default value) are unaffected. Instances with the enable_media_repo configuration option set to false are also unaffected, as this also disables the URL preview functionality.

Server administrators who are unable to update Synapse should disable URL previews by setting url_preview_enabled: false 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.

Please see this security advisory for more information.

0.34.0 security release for matrix-appservice-irc (High severity)

04.05.2022 11:02 — Releases Tadeusz Sośnierz
Last update: 04.05.2022 09:27

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.

The vulnerability allows an attacker to manipulate a Matrix user into executing IRC commands by having them reply to a maliciously crafted message.

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.

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.

The vulnerability has been patched in node-irc version 1.2.1 and matrix-appservice-irc 0.34.0. You can get the release on Github.

The bridges running on the Libera Chat, OFTC and other networks bridged by the Matrix.org Foundation have been patched.

The vulnerabilities are tracked as GHSA-37hr-348p-rmf4 and GHSA-52rh-5rpj-c3w6.

Thank you, Val Lorentz for reporting this vulnerability.

High severity vulnerability in Element Desktop 1.9.6 and earlier

31.01.2022 14:01 — Security Matrix Security Team

Element Desktop 1.9.6 and earlier depend on a vulnerable version of Electron, leading to a High severity vulnerability 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.

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 has been research demonstrating that the ability to open arbitrary URLs can sometimes lead to arbitrary code execution.

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.

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 CVE-2022-23597.

Discovered and reported by Sirius and TheGrandPew.

On Matrix and the log4j vulnerabilities

15.12.2021 12:58 — Security Matrix Security Team

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.

First and foremost, there are to our knowledge no Matrix homeservers written in Java. Synapse, 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 Dendrite, our next-gen homeserver which is written in Go and is unaffected. Conduit, a community homeserver, is written in Rust and also unaffected. Supporting components like Sygnal and Sydent are written in Python and unaffected.

There are two components that are commonly used in the Matrix ecosystem that do rely on Java. These are Jitsi, specifically the Jitsi Videobridge for VoIP, and signald 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.

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.

For what mitigations to put in place, we recommend following the recommendations provided by LunaSec. They also provide a lot of background information on the vulnerabilities and how to audit for them.

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.

Disclosure: buffer overflow in libolm and matrix-js-sdk

13.12.2021 18:35 — Security Matrix Security Team
Last update: 13.12.2021 16:11

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 pre-disclosure issued on December 3rd.

Fixed library versions are:

Client versions incorporating the fixes are:

These releases mitigate a buffer overflow in olm_session_describe, 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 CVE-2021-44538.

Clients which do not use matrix-js-sdk for E2EE, like FluffyChat or Element Android / iOS, are not affected.

This issue has been present since the introduction of the olm_session_describe function in October 2019 (commits: libolm, matrix-js-sdk).

We do not believe it is practical to successfully exploit this issue. However, upgrading remains important as the overflow can be triggered remotely.

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.

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.

The buffer overflow was found and reported by GitHub user @brevilo in the course of developing jOlm, 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 Security Disclosure Policy for how to get in touch.

Pre-disclosure: upcoming security release of libolm and matrix-js-sdk

03.12.2021 00:00 — Security Matrix Security Team

On Monday, 13th December 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 upgrade as soon as the patched versions are released.

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.

The patched version numbers will be as follows:

  • libolm 3.2.8
  • matrix-js-sdk 15.2.1
  • Element Web/Desktop 1.9.7

Thank you for your patience while we work to resolve this issue.

Edit, 2021-12-13: Added patched release numbers.

Synapse 1.47.1 released

23.11.2021 12:46 — Releases David Robertson

Today we are releasing Synapse 1.47.1, a security update based on last week's release of Synapse 1.47.0. This release patches one high severity issue affecting Synapse installations 1.47.0 and earlier using the media repository. An attacker could cause these Synapses to download a remote file and store it in a directory outside the media repository.

Note that:

To quote from the advisory:

GHSA-3hfw-x7gx-437c / CVE-2021-41281: Path traversal when downloading remote media.

Impact

Synapse instances with the media repository enabled can be tricked into downloading a file from a remote server into an arbitrary directory, potentially outside the media store directory.

The last two directories and file name of the path are chosen randomly by Synapse and cannot be controlled by an attacker, which limits the impact.

Homeservers with the media repository disabled are unaffected. Homeservers configured with a federation whitelist are also unaffected.

The advisory has full details, including workarounds.

This issue was discovered and fixed by our internal security team.

Please update at your earliest convenience.

Pre-disclosure: upcoming security release of Synapse 1.47.1

18.11.2021 00:00 — Security Matrix Security Team

On Tuesday, 23rd November we plan to release Synapse 1.47.1 at 12:00 UTC to address a single high severity issue. This vulnerability was discovered internally by our security team. Synapse is a Matrix homeserver implementation developed by the matrix.org team and the wider Matrix community.

If you're a server administrator running Synapse, please be prepared to upgrade as soon as the patched version is released.

We will be reaching out to downstream packagers to ensure they can prepare patched versions of 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.

Thank you for your patience while we work to resolve this issue.

Edit, 2021-11-19: The opening paragraph was amended to note that the vulnerability was discovered internally.

Edit, 2021-11-22: The opening paragraph was amended to include a release time of 12:00 UTC.

Disclosing CVE-2021-40823 and CVE-2021-40824: E2EE vulnerability in multiple Matrix clients

13.09.2021 17:29 — Security Denis Kasak

Today we are disclosing a critical security issue affecting multiple Matrix clients and libraries including Element (Web/Desktop/Android), FluffyChat, Nheko, Cinny, and SchildiChat. Element on iOS is not affected.

Specifically, in certain circumstances it may be possible to trick vulnerable clients into disclosing encryption keys for messages previously sent by that client to user accounts later compromised by an attacker.

Exploiting this vulnerability to read encrypted messages requires gaining control over the recipient’s account. This requires either compromising their credentials directly or compromising their homeserver.

Thus, the greatest risk is to users who are in encrypted rooms containing malicious servers. Admins of malicious servers could attempt to impersonate their users' devices in order to spy on messages sent by vulnerable clients in that room.

This is not a vulnerability in the Matrix or Olm/Megolm protocols, nor the libolm implementation. It is an implementation bug in certain Matrix clients and SDKs which support end-to-end encryption (“E2EE”).

We have no evidence of the vulnerability being exploited in the wild.

This issue was discovered during an internal audit by Denis Kasak, a security researcher at Element.

Remediation and Detection

Patched versions of affected clients are available now; please upgrade as soon as possible — we apologise sincerely for the inconvenience. If you are unable to upgrade, consider keeping vulnerable clients offline until you can. If vulnerable clients are offline, they cannot be tricked into disclosing keys. They may safely return online once updated.

Unfortunately, it is difficult or impossible to retroactively identify instances of this attack with standard logging levels present on both clients and servers. However, as the attack requires account compromise, homeserver administrators may wish to review their authentication logs for any indications of inappropriate access.

Similarly, users should review the list of devices connected to their account with an eye toward missing, untrusted, or non-functioning devices. Because an attacker must impersonate an existing or historical device, exploiting this vulnerability would either break an existing login on the user’s account, or a historical device would be re-added and flagged as untrusted.

Lastly, if you have previously verified the users / devices in a room, you would witness the safety shield on the room turn red during the attack, indicating the presence of an untrusted and potentially malicious device.

Affected Software

Given the severity of this issue, Element attempted to review all known encryption-capable Matrix clients and libraries so that patches could be prepared prior to public disclosure.

Known vulnerable software:

We believe the following software is not vulnerable:

We believe the following are not vulnerable due to not implementing key sharing:

Background

Matrix supports the concept of “key sharing”, letting a Matrix client which lacks the keys to decrypt a message request those keys from that user's other devices or the original sender's device.

This was a feature added in 2016 in order to address edge cases where a newly logged-in device might not have the necessary keys to decrypt historical messages. Specifically, if other devices in the room are unaware of the new device due to a network partition, they have no way to encrypt for it—meaning that the only way the new device will be able to decrypt history is if the recipient's other devices share the necessary keys with it.

Other situations where key sharing is desirable include when the recipient hasn't backed up their keys (either online or offline) and needs them to decrypt history on a new login, or when facing implementation bugs which prevent clients from sending keys correctly. Requesting keys from a user's other devices sidesteps these issues.

Key sharing is described here in the Matrix E2EE Implementation Guide, which contains the following paragraph:

In order to securely implement key sharing, clients must not reply to every key request they receive. The recommended strategy is to share the keys automatically only to verified devices of the same user.

This is the approach taken in the original implementation in matrix-js-sdk, as used in Element Web and others, with the extension of also letting the sending device service keyshare requests from recipient devices. Unfortunately, the implementation did not sufficiently verify the identity of the device requesting the keyshare, meaning that a compromised account can impersonate the device requesting the keys, creating this vulnerability.

This is not a protocol or specification bug, but an implementation bug which was then unfortunately replicated in other independent implementations.

While we believe we have identified and contacted all affected E2EE client implementations: if your client implements key sharing requests, we strongly recommend you check that you cryptographically verify the identity of the device which originated the key sharing request.

Next Steps

The fact that this vulnerability was independently introduced so many times is a clear signal that the current wording in the Matrix Spec and the E2EE Implementation Guide is insufficient. We will thoroughly review the related documentation and revise it with clear guidelines on safely implementing key sharing.

Going further, we will also consider whether key sharing is still a necessary part of the Matrix protocol. If it is not, we will remove it. As discussed above, key sharing was originally introduced to make E2EE more reliable while we were ironing out its many edge cases and failure modes. Meanwhile, implementations have become much more robust, to the point that we may be able to go without key sharing completely. We will also consider changing how we present situations in which you cannot decrypt messages because the original sender was not aware of your presence. For example, undecryptable messages could be filed in a separate conversation thread, or those messages could require that keys are shared manually, effectively turning a bug into a feature.

We will also accelerate our work on matrix-rust-sdk as a portable reference implementation of the Matrix protocol, avoiding the implicit requirement that each independent library must necessarily reimplement this logic on its own. This will have the effect of reducing attack surface and simplifying audits for software which chooses to use matrix-rust-sdk.

Finally, we apologise to the wider Matrix community for the inconvenience and disruption of this issue. While Element discovered this vulnerability during an internal audit of E2EE implementations, we will be funding an independent end-to-end audit of the reference Matrix E2EE implementations (not just Olm + libolm) in the near future to help mitigate the risk from any future vulnerabilities. The results of this audit will be made publicly available.

Timeline

Ultimately, Element took two weeks from initial discovery to completing an audit of all known, public E2EE implementations. It took a further week to coordinate disclosure, culminating in today's announcement.

  • Monday, 23rd August — Discovery that Element Web is exploitable.
  • Thursday, 26th August — Determination that Element Android is exploitable with a modified attack.
  • Wednesday, 1 September — Determination that Element iOS fails safe in the presence of device changes.
  • Friday, 3 September — Determination that FluffyChat and Nheko are exploitable.
  • Tuesday, 7th September — Audit of Matrix clients and libraries complete.
  • Wednesday, 8th September — Affected software authors contacted, disclosure timelines agreed.
  • Friday, 10th September — Public pre-disclosure notification. Downstream packagers (e.g., Linux distributions) notified via Matrix and e-mail.
  • Monday, 13th September — Coordinated releases of all affected software, public disclosure.

Pre-disclosure: upcoming critical fix for several popular Matrix clients

10.09.2021 16:43 — Security Matrix Security Team

Hi all,

A critical security vulnerability impacting several popular Matrix clients and libraries was recently discovered. A coordinated security release of the affected components will be happening in the afternoon (from an UTC perspective) of Monday, Sept 13th.

We will be reaching out to downstream packagers to ensure they can prepare patched versions of 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.

Please be prepared to upgrade as soon as the patched versions are released.

Thank you for your patience while we work to resolve this issue.