Security Issues in Matrix's Olm Library
soatok.blog
Security Issues in Matrix's Olm Library
1–10 of 24 posts
Re: Security Issues in Matrix's Olm Library
#2Might be slightly OT, but let's go. I think that this highly relates to how translations units are organized in a software project. At some point I think that mutual dependency is not a problem as long as the units form a unique "package".
Re: Security Issues in Matrix's Olm Library
#3>> "3 of the 16 clients surveyed use the new vodozemac library. 10 still use libolm, and 3 don’t appear to implement end-to-end encryption at all."
This soesn't bode well for it as an option for secure messaging. Wouldn't be a problem if I didn't see people suggesting it as one.
Re: Security Issues in Matrix's Olm Library
#4>> "3 of the 16 clients surveyed use the new vodozemac library. 10 still use libolm, and 3 don’t appear to implement end-to-end encryption at all." This soesn't bode well for it as an option for secure messaging. Wouldn't be a problem if I didn't see people suggesting it as one.
the author literally picked random projects from github tagged as matrix, without considering their prevalence or whether they are actually maintained etc.
if you actually look at % of impacted clients, it’s tiny.
meanwhile, it is very unclear that any sidechannel attack on a libolm based client is practical over the network (which is why we didn’t fix this years ago). After all, the limited primitives are commented on in the readme and https://github.com/matrix-org/olm/issues/3 since day 1.
Re: Security Issues in Matrix's Olm Library
#5>> "3 of the 16 clients surveyed use the new vodozemac library. 10 still use libolm, and 3 don’t appear to implement end-to-end encryption at all." This soesn't bode well for it as an option for secure messaging. Wouldn't be a problem if I didn't see people suggesting it as one.
the author literally picked random projects from github tagged as matrix, without considering their prevalence or whether they are actually maintained etc. if you actually look at % of impacted clients, it’s tiny. meanwhile, it is very unclear that any sidechannel attack on a libolm based client is practical over the network (which is why we didn’t fix this years ago). After all, the limited primitives are commented…
> the author literally picked random projects from github tagged as matrix, without considering their prevalence or whether they are actually maintained etc.
I was very clear in my methodology: I grabbed everything tagged with that GitHub topic, and filtered out projects that were archived or marked as "old".
> meanwhile, it is very unclear that any sidechannel attack on a libolm based client is practical over the network (which is why we didn’t fix this years ago).
This is not an attitude that inspires confidence.
It's one thing to accidentally ship cryptography code with side-channels. It's another entirely to knowingly do so, and not fix it sooner.
What the fuck.
Re: Security Issues in Matrix's Olm Library
#6oh. ohhh damn. matrix... well then.
Re: Security Issues in Matrix's Olm Library
#7>> "3 of the 16 clients surveyed use the new vodozemac library. 10 still use libolm, and 3 don’t appear to implement end-to-end encryption at all." This soesn't bode well for it as an option for secure messaging. Wouldn't be a problem if I didn't see people suggesting it as one.
the author literally picked random projects from github tagged as matrix, without considering their prevalence or whether they are actually maintained etc. if you actually look at % of impacted clients, it’s tiny. meanwhile, it is very unclear that any sidechannel attack on a libolm based client is practical over the network (which is why we didn’t fix this years ago). After all, the limited primitives are commented…
projects that import the SDK /written by and (un)maintained by the matrix org/
e.g.: https://github.com/matrix-org/matrix-python-sdk (dependents doesn't work on this python project I guess)
or matrix-org/olm for JS
or matrix-org/matrix-js-sdk
or matrix-nio/matrix-nio (based on an old standard written by matrix, that matrix stayed compatible with rather than deprecating)
the inability to address the third issue (a security issue, no less) in 7 years is an impressive world record in incompetent messenger design
Re: Security Issues in Matrix's Olm Library
#8>> "3 of the 16 clients surveyed use the new vodozemac library. 10 still use libolm, and 3 don’t appear to implement end-to-end encryption at all." This soesn't bode well for it as an option for secure messaging. Wouldn't be a problem if I didn't see people suggesting it as one.
the author literally picked random projects from github tagged as matrix, without considering their prevalence or whether they are actually maintained etc. if you actually look at % of impacted clients, it’s tiny. meanwhile, it is very unclear that any sidechannel attack on a libolm based client is practical over the network (which is why we didn’t fix this years ago). After all, the limited primitives are commented…
I usually keep myself out of HN discussions but some clients's issues are listed at https://github.com/NixOS/nixpkgs/pull/334638 from Nix's side, which includes Cinny, Fluffychat, nheko, which are the 3 non-Element "Featured clients" listed on Matrix.org.
Re: Security Issues in Matrix's Olm Library
#9>> "3 of the 16 clients surveyed use the new vodozemac library. 10 still use libolm, and 3 don’t appear to implement end-to-end encryption at all." This soesn't bode well for it as an option for secure messaging. Wouldn't be a problem if I didn't see people suggesting it as one.
the author literally picked random projects from github tagged as matrix, without considering their prevalence or whether they are actually maintained etc. if you actually look at % of impacted clients, it’s tiny. meanwhile, it is very unclear that any sidechannel attack on a libolm based client is practical over the network (which is why we didn’t fix this years ago). After all, the limited primitives are commented…
It being unclear that they're exploitable doesn't justify the fact that the reference implementation had known weaknesses that were only documented in the issue tracker and a readme buried several directories deep and not referenced from elsewhere! It also doesn't justify failing to proactively inform any of the clients making use of olm that these issues had been identified, and now anyone who does feel that this is inside their code's threat model has to rush to port to the new implementation after public disclosure.
Edit: but also if you're going to argue that it's unclear that these issues are remotely exploitable, it'd be helpful to discuss why - are there external constraints that ratelimit them such that the number of packets required is infeasible in any length of time? Is all the affected key material ephemeral and rotated before it's realistic to get a large enough sample? Just vibes?
Re: Security Issues in Matrix's Olm Library
#10In general, can timing attacks on a vulnerable implementation be prevented if sonething else guarantees the operation takes constant time?
For example, if I add a sleep after a non-constant-time operation to ensure it always takes 1s, would that prevent timing attacks? At least with this you can use a faster algorithm, and let the OS do useful work with the rest of the time.