4 ms·

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

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.

tptacek 4y ago
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.enteract.com/~tqbf/bug-reports.html https://web.archive.org/web/20000818162612/http://www.entera...
- pseudo0 4y ago
  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.
  - tptacek 4y ago
    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.
    - dfgdfgffd 4y ago
      You can't decrypt all the messages, but only the ones sent despite warning
      - tptacek 4y ago
        This is an amazing assertion.
    - pseudo0 4y ago
      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.
      - tptacek 4y ago
        "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.)
        pseudo0 4y ago
        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.
        tptacek 4y ago
        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?
  - martinralbrecht 4y ago
    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.
    - Arathorn 4y ago
      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.
      - tptacek 4y ago
        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?
- pkulak 4y ago
  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?
  - tptacek 4y ago
    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.
    - dodgerdan 4y ago
      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.
      - Arathorn 4y ago
        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-of-vodozemac-a-native-rust-reference-implementation-of-matrix-end-to-end-encryption 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/fayed/cryptographic-membership/proposals/3917-cryptographic-membership.md 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.
        tptacek 4y ago
martinralbrecht 4y ago
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.
- cvwright 4y ago
  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.

tptacek 4y ago

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.enteract.com/~tqbf/bug-reports.html https://web.archive.org/web/20000818162612/http://www.entera...

pseudo0 4y ago
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.
- tptacek 4y ago
  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.
  - dfgdfgffd 4y ago
    You can't decrypt all the messages, but only the ones sent despite warning
    - tptacek 4y ago
      This is an amazing assertion.
  - pseudo0 4y ago
    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.
    - tptacek 4y ago
      "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.)
      - pseudo0 4y ago
        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.
        tptacek 4y ago
        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?
- martinralbrecht 4y ago
  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.
  - Arathorn 4y ago
    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.
    - tptacek 4y ago
      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?
pkulak 4y ago
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?
- tptacek 4y ago
  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.
  - dodgerdan 4y ago
    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.
    - Arathorn 4y ago
      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-of-vodozemac-a-native-rust-reference-implementation-of-matrix-end-to-end-encryption 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/fayed/cryptographic-membership/proposals/3917-cryptographic-membership.md 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.
      - tptacek 4y ago

martinralbrecht 4y ago

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.

cvwright 4y ago
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.