Security Issues in Matrix’s Olm Library - Dhole Moments
soatok.blog
I don’t consider myself exceptional in any regard, but I stumbled upon a few cryptography vulnerabilities in Matrix’s Olm library with so little effort that it was nearly accidental. It…

I don’t consider myself exceptional in any regard, but I stumbled upon a few cryptography vulnerabilities in Matrix’s Olm library with so little effort that it was nearly accidental.

It should not be this easy to find these kind of issues in any product people purportedly rely on for private messaging, which many people evangelize incorrectly as a Signal alternative.

  • mox@lemmy.sdf.orgEnglish
    25·
    3 months ago

    FWIW, current versions of the reference client (Element) don’t use the Olm library (libolm), which is now deprecated.

    From the README:

    libolm was Matrix’s first implementation of the Double Ratchet algorithm, dating back to 2015. It is not written in memory-safe langauges (C and C++11), resulting in several CVEs over the years (e.g. CVE-2021-34813 and CVE-2021-44538). It also depends on simplistic cryptography primitive implementations which are intended for pragmatic and education purposes rather than security - e.g. Brad Conte’s crypto-algorithms.

    As a result, we rewrote libolm in Rust in December 2021 - the result being vodozemac, and announced it as the recommended successor to libolm after its audit by Least Authority in May 2022

    Also, from the latest weekly update:

    We’re not aware of any way to actually exploit these weaknesses over the network, but we continue to strongly recommend developers to migrate to vodozemac (or fork libolm to add better primitives).

    Nevertheless, if you’re using a third-party Matrix client that depends on libolm, you might want to contact its developers, or switch.