1744056 - (CVE-2021-44538) Security vulnerability in libolm (used by Matrix)

Status: RESOLVED FIXED

(Chat Core :: Matrix, defect)

Description

[Patrick Cloke [:clokep]]

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.

Comment 1

[Patrick Cloke [:clokep]]

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.

Comment 2

[Martin Giger [:freaktechnik]]

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.

Comment 3

[Patrick Cloke [:clokep]]

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?

Comment 4

[Martin Giger [:freaktechnik]]

Attachment: Bug 1744056 - Update matrix-js-sdk and libolm. r=mkmelin

Comment 5

[Rob Lemley [:rjl]]

Building 96.0beta2 today.

Comment 6

[Martin Giger [:freaktechnik]]

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

Comment 7

[Martin Giger [:freaktechnik]]

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.

Comment 8

[Patrick Cloke [:clokep]]

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

Comment 9

[Rob Lemley [:rjl]]

https://hg.mozilla.org/comm-central/rev/fc85133614aa740e40346893c8c8acaabe445be2

Comment 10

[Rob Lemley [:rjl]]

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

[Triage Comment]
Approved for 96.0b2

Comment 11

[Rob Lemley [:rjl]]

Thunderbird 96.0b2:
https://hg.mozilla.org/releases/comm-beta/rev/b2eb863fec9a6074f6a5d0b0bb76b5598609c6e7

Comment 12

[Patrick Cloke [:clokep]]

Full disclosure blog post: https://matrix.org/blog/2021/12/13/disclosure-buffer-overflow-in-libolm-and-matrix-js-sdk

Comment 13

[Martin Giger [:freaktechnik]]

Attachment: bug1744056-esr.patch

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

Comment 14

[Patrick Cloke [:clokep]]

(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).

Comment 15

[Martin Giger [:freaktechnik]]

(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.

Comment 16

[Martin Giger [:freaktechnik]]

Attachment: bug1744056-esr-v2.patch

Aslo update the libolm version in the README

Comment 17

[Martin Giger [:freaktechnik]]

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)

Comment 18

[Wayne Mery (:wsmwk)]

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

[Triage Comment]
Approved for esr91

Comment 19

[Rob Lemley [:rjl]]

Thunderbird 91.4.1:
https://hg.mozilla.org/releases/comm-esr91/rev/b9a16e74e72c

Comment 20

[Kai Engert (:KaiE:)]

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?

Comment 21

[Kai Engert (:KaiE:)]

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?

Comment 22

[Patrick Cloke [:clokep]]

(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).

Comment 23

[Tom Ritter [:tjr]]

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.

Comment 24

[Kai Engert (:KaiE:)]

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

Comment 25

[Tom Ritter [:tjr]]

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.