Hacker News Reader

Comment by pseudo0 | Hacker News Reader

It has been a bit since I read the paper, but my recollection was that the attacks weren't very practical. It's great that they responsibly disclosed issues and that Matrix tightened up the spec and implementations, but requiring a malicious homeserver plus additional preconditions made the attacks quite slim edge cases.

View on HN

We had working exploits for those vulnerabilities where exploiting them wasn't immediately obvious. We shared those with the Matrix developers but didn't publish them because there was no dispute on whether our attacks were practical. So we meant it when we wrote "practically-exploitable".

In an end-to-end encrypted setting a malicious server is precisely the adversary you defend against, not an edge case.

I would love to hear what you and your team think about Matrix’s proposed fixes, especially MSC3917.

To me, it looks pretty good on the surface, but I don’t know if I can convince myself that it’s secure. I’m not even sure if I could write down a precise definition of security here, without banging my head on it for a while.

In practice, all Matrix messages are group messages. Servers control group membership. That's it, that's the tweet.

People have been dismissing security research with this "not very practical" epithet for as long as I've been working. Literally, at least since I got into the field.

https://web.archive.org/web/20000818162612/http://www.entera...

My background is more in the applied end of things, not research, so I suppose that colors my perspective.

But let's say I'm playing red team, and I get root on the box where my target is running their Matrix server. Practically, what can I do to extract information without setting off giant red flags? From my read of the paper the answer is "not much", since a bunch of big warnings popping up would probably alert the users that something sketchy is happening.

This isn't correct. Several of our attacks succeeded without any warnings popping up.

Furthermore, you need to distinguish between what Element happened to do (which users may or may not watch out for) and what the standard demanded.

Note that at this point, as far as I understand it, there is no dispute between us - the authors of this research - and the Matrix developers about that leaving group membership under the control of the server was a bad and avoidable design decision. The Matrix developers are working on a spec change/fix which resolves this, linked elsewhere in this thread.

The problem is that the paper conflates legitimate implementation vulns (fixed back in Sept) which indeed allowed for practical attacks… with the “group membership controlled by server” issue, which is debatable. Hence folks writing off the remaining issues as ‘academic at best’.

It really would have been better to separate the legit vulns from the group membership question, as mixing them up just confuses people, as per this whole thread.

Can I ask what's debatable about the group membership issue? That it exists, or that it's as important as people like me say it is?

If you're red-teaming a Matrix server and you own up the server, you can decrypt all the messages of all the people using that Matrix server, and you can do it trivially, just using the basic protocol messages. Users might see extra group members in their groups and they might not, depending in part on whether they're running the most current version of the software.

You can decrypt all the messages. I sometimes feel like I must have read a different paper than everybody else.

You can decrypt all future messages in a noisy way that alerts all the users that something weird is going on.

> While the Matrix specification does not require a mitigation of this behaviour, when a user is added to a room, Element will display this as an event in the timeline. Thus, to users of Element this is detectable.

Virtually everyone uses Element, so it's blatantly tamper-evident. That makes it a really bad option if red-teaming.

"Tamper-evident", meaning, Element will list the string name of the member the server injected into your group in the group list.

(Here it's worth noting that this is the behavior post-fix for this paper. Read the paper! It was so much worse.)

I have used Element, and new users joining a room are displayed as an event in the timeline. The paper confirms that in section III-A, and based on the context I'm 99% sure that they mean pre-fix, not post-fix.

With III-B, they can add an unverified device, but that causes a warning for every other room participant. Again, tamper evident.

We're clear that this is "an event in your timeline" that says "the server might be decrypting all your messages or maybe a new participant joined your group", right?

If some random user joins my E2EE groupchat, yes, my expectation is that some unknown actor is now reading my messages... It would be no different than some rando getting added to a Signal group. At least in the groups I'm in, that would cause a flurry of messages asking who they are and who added them.

What if someone already in the group adds a new device? That would hardly cause a flurry or surprise, it’s a common thing to happen. But using Matrix it could also mean whom ever controls the server could be reading all your messages. And the alert has to cover both scenarios. I’m not sure how you could message that in such a way to make it actionable. Especially to non-tech users. Even if they did understand it would require a mini investigation/“flurry” multiple times a month for even a modest sized group. My personal observation is that a group of about 50 have 1 new phone every two weeks, with seasonal increases around Sept/Oct and January 1st.

If verified that device will show up red. And you can enable sending keys only to verified contacts

You can't decrypt all the messages, but only the ones sent despite warning

This is an amazing assertion.

Someone needs to invite a malicious homeserver to the group.

So what’s the scenario here? You have an encrypted group chat with so many members that some rando nefarious user can slip in? And then the big deal is that the E2E breaks down, so the home server that they probably own can read the messages that they are already reading?

We are talking about end-to-end encryption. "Malicious homeserver" is literally the table stakes. If you trust your server, you can use anything. Go ahead and use Slack.

This is the issue distilled. And the retort seems to be “but we give a warning”.

Awfully weak stuff for a cypherpunk-ish protocol. The CCC crowd that rabidly hates anything centralised, thinks it’s insecure and corporate, are probably having a existential crisis. Matrix is doing a terrible job fixing the issues, worse they seem to downplaying and denying too. And the Tech press seem to dismiss the issue believing Matrixs’ claims there isn’t an issue.

I’m sorry - how are we doing a terrible job fixing the issues? We are working solidly to switch Element over to the newly audited vodozemac crypto implementation (https://matrix.org/blog/2022/05/16/independent-public-audit-...), and then implementing both TOFU and client-controlled group membership. https://github.com/matrix-org/matrix-spec-proposals/blob/fay...

We are not denying these issues - we just dare to disagree that they are as catastrophic as some suggest.

Just so we're clear, I didn't say that you're doing a terrible job fixing the issues (I know the comment you're responding to said that, I'm just being careful not to cosign that.)

Reply on news.ycombinator.com