Closed Bug 1744056 (CVE-2021-44538) Opened 1 year ago Closed 1 year ago

Security vulnerability in libolm (used by Matrix)

Categories

(Chat Core :: Matrix, defect)

defect

Tracking

(thunderbird_esr91+ fixed, thunderbird96 fixed, thunderbird97 fixed)

RESOLVED FIXED
97 Branch
Tracking Status
thunderbird_esr91 + fixed
thunderbird96 --- fixed
thunderbird97 --- fixed

People

(Reporter: clokep, Assigned: freaktechnik)

References

()

Details

(Keywords: sec-moderate)

Attachments

(2 files, 1 obsolete file)

A new libolm release (v3.2.7) is going to happen next week due to a security vulnerability. Consumers of matrix-js-sdk + libolm are vulnerable.

A pre-disclosure should be announced shortly on the Matrix blog (I'll link to it when it is available). A CVE number is forthcoming.

I think that we're going to want to upgrade libolm on both comm-central and comm-beta. Martin -- any thoughts on if we should upgrade it in comm-esr91 too? I think we don't really use libolm there, but might be best to upgrade anyway?

I do not think we'll need to upgrade matrix-js-sdk at the same time, which makes this easier.

I'm unsure if we'll need to do security releases or not, might depend on when we're next doing builds anyway.

Thanks! I'm pretty sure this is going to actually be v3.2.8 (not 3.2.7) since another release is scheduled this week or something.

Anyway, the useful info is that this will be on Monday, December 13, 2021 @ 15:00 UTC.

I'll try to get the patches ready ASAP next Monday. I've also already tested the matrix-js-sdk upgrade to the current latest version.

Assignee: nobody → martin
Status: NEW → ASSIGNED

The current state of E2EE in Matrix related to this is:

  • Matrix is only enabled on Thunderbird nightlies, but a user could manually enable it on beta or ESR91.
  • E2EE support for Matrix is merged up-to Thunderbird beta.
  • Thunderbird ESR 91 does have libolm and is loaded (bug 1712944), but not really used.

I think we should:

  • Apply the updates to the matrix-js-sdk + libolm to both Nightly and Beta.
  • Just update libolm on Thunderbird ESR 91. (It is backwards compatible so there shouldn't be an issues, but no reason to not get protection there.)

If we're doing a beta "soon" I don't think we would need any dedicated releases.

Note that the pre-disclosure (https://matrix.org/blog/2021/12/03/pre-disclosure-upcoming-security-release-of-libolm-and-matrix-js-sdk) has been updated with version numbers:

The patched version numbers will be as follows:

  • libolm 3.2.8
  • matrix-js-sdk 15.2.1

These should both be on npm now.

Does that sound reasonable to all?

Building 96.0beta2 today.

Currently checking if the c-c patch applies to beta cleanly.

Comment on attachment 9255054 [details]
Bug 1744056 - Update matrix-js-sdk and libolm. r=mkmelin

[Approval Request Comment]
Regression caused by (bug #): -
User impact if declined: Users that enabled matrix via pref will be using encryption with big security issues.
Testing completed (on c-c, etc.): tested manually on trunk, patch applies to c-b, can't build c-b sadly.
Risk to taking this patch (and alternatives if risky): Worst case this breaks matrix on beta I'd think, though given it works fine on trunk I don't think there should be any compat issues.

Attachment #9255054 - Flags: approval-comm-beta?

Note that this was assigned CVE-2021-44538, but isn't published there yet.

Alias: CVE-2021-44538

Comment on attachment 9255054 [details]
Bug 1744056 - Update matrix-js-sdk and libolm. r=mkmelin

[Triage Comment]
Approved for 96.0b2

Attachment #9255054 - Flags: approval-comm-beta? → approval-comm-beta+
Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Attached patch bug1744056-esr.patch (obsolete) — Splinter Review

Stripped down ESR version that only updates the two libolm files.

(In reply to Martin Giger [:freaktechnik] from comment #13)

Created attachment 9255221 [details] [diff] [review]
bug1744056-esr.patch

Stripped down ESR version that only updates the two libolm files.

I don't think this updated the WASM file? It would also be good to still update the README file in there so that the version number in there matches the version of libolm in use (to avoid future confusion).

(In reply to Patrick Cloke [:clokep] from comment #14)

(In reply to Martin Giger [:freaktechnik] from comment #13)
I don't think this updated the WASM file? It would also be good to still update the README file in there so that the version number in there matches the version of libolm in use (to avoid future confusion).

Bugzilla doesn't render the "GIT binary patch" part of the diff, you have to look at the raw patch for that.

Sure, I can add that, though the js file does contain its own version at the very top.

Aslo update the libolm version in the README

Attachment #9255221 - Attachment is obsolete: true

Comment on attachment 9255240 [details] [diff] [review]
bug1744056-esr-v2.patch

[Approval Request Comment]
Regression caused by (bug #): -
User impact if declined: Matrix is insecure
Testing completed (on c-c, etc.): none relevant to this patch, but only changes the libolm library version, which should be API compatible.
Risk to taking this patch (and alternatives if risky): Worst case encryption doesn't work (which might be better than encryption is insecure)

Attachment #9255240 - Flags: approval-comm-esr91?

Comment on attachment 9255240 [details] [diff] [review]
bug1744056-esr-v2.patch

[Triage Comment]
Approved for esr91

Attachment #9255240 - Flags: approval-comm-esr91? → approval-comm-esr91+

Patrick and Tom, if I understand correctly, CVE-2021-44538 has been assigned to the issue in the library.

Do we need a separate CVE for Thunderbird?
If you think that the Thunderbird release notes should mention that we have fixed the issue in TB, then I think we need a separate CVE, right?

Should we copy the advisory text, or is there anything we should mention that is specific to Thunderbird?

Flags: needinfo?(tom)
Flags: needinfo?(clokep)

Patrick, which security rating should this bug get, based on the categories here?
https://wiki.mozilla.org/Security_Severity_Ratings/Client
low, medium, high or critical?

(In reply to Kai Engert (:KaiE:) from comment #20)

Patrick and Tom, if I understand correctly, CVE-2021-44538 has been assigned to the issue in the library.

This is correct, it is the CVE assigned to libolm.

Do we need a separate CVE for Thunderbird?
If you think that the Thunderbird release notes should mention that we have fixed the issue in TB, then I think we need a separate CVE, right?

I do not know how this process usually works. I defer to whatever we usually do for CVEs in other packages which affect us.

Should we copy the advisory text, or is there anything we should mention that is specific to Thunderbird?

The only specific to mention about Thunderbird is that it could only affect user if you have a Matrix account configured.

(In reply to Kai Engert (:KaiE:) from comment #21)

Patrick, which security rating should this bug get, based on the categories here?
https://wiki.mozilla.org/Security_Severity_Ratings/Client
low, medium, high or critical?

Reading through those I think it should probably be medium as the disclosure says it is not exploitable, or maybe low since there isn't any leak of information due to it? (Note that the predisclosure calls it "high severity" but there's no documented system for Matrix to assign low/medium/high so it is hard to know how they came up with that description).

Flags: needinfo?(clokep)

No; no separate CVE. This is pretty much the same situation we have when there's a bug upstream in e.g. Angle - we use their CVE and do not issue our own.

Flags: needinfo?(tom)

But I assume we nevertheless publish our own advisory, we simply point to the same CVE?

Attempted summary:

CVE-2021-44538:
    title: Matrix chat library libolm bundled with Thunderbird vulnerable to a buffer overflow
    impact: moderate
    reporter: brevilo
    description: |
      Thunderbird users who use the Matrix chat protocol were vulnerable
to a buffer overflow in libolm, that an attacker may trigger by a crafted
sequence of  messages. The overflow content is partially controllable
by the attacker and limited to ASCII spaces and digits.
    bugs:
      - url: 1744056
Keywords: sec-moderate

Yeah that's fine. We also add publish: false into the yaml so we don't try to publish someone else's CVE but I'll handle that.

Group: mail-core-security → core-security-release
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.