Practically-Exploitable Cryptographic Vulnerabilities in Matrix(nebuchadnezzar-megolm.github.io)
nebuchadnezzar-megolm.github.io
Practically-Exploitable Cryptographic Vulnerabilities in Matrix
https://nebuchadnezzar-megolm.github.io/
64 comments
To paraphrase another comment on this; if I have to trust the server for Matrix E2EE to work, why don’t I just use Slack? The whole point of E2EE is so you don’t have to trust the server.
And a “warning” that says something like “your group chat has been compromised by someone with access to the server or it might just be bob bought a new phone” is laughable as a status quo.
And a “warning” that says something like “your group chat has been compromised by someone with access to the server or it might just be bob bought a new phone” is laughable as a status quo.
The point is that if your threat model cares about interception, you have to verify the identity of users out of band - same as Signal or WhatsApp or whatever.
Then, if you've done that, and an unverified device is added to the conversation, the warning shows up and explicitly means "your group chat has been compromised" - just like a big red TLS warning on a webpage means "this certificate is bad". It does *NOT* mean that "it might just be bob bought a new phone"; if bob bought a new phone, he'll have verified it when he logged in, and so the warning doesn't show up.
Anyone who actually uses Matrix will be familiar with the fact that it's pretty rare to see a big red X on a user who you've verified, and when it happens, you go ping them to ask wtf is going on - much like you'd ping the webmaster of a site whose TLS certificate is bad. This is why the Matrix community is not up in arms about this "vulnerability" - it is literally following the intended design, right from the point that we announced verification back in https://element.io/blog/e2e-encryption-by-default-cross-sign....
Now, this design can absolutely be improved on - at the least, we could go back to freezing the room whenever there's an unverified device, forcing the users to decide how to flush out the old device. Or we could switch to TOFU, and block unverified devices by default. But we've chosen to prioritise migrating the clients onto a single E2EE codebase (matrix-rust-sdk-crypto) first, so we do that work in a single place, rather than in quadruplicate across matrix-{js,ios,android,rust}-sdk.
Then, if you've done that, and an unverified device is added to the conversation, the warning shows up and explicitly means "your group chat has been compromised" - just like a big red TLS warning on a webpage means "this certificate is bad". It does *NOT* mean that "it might just be bob bought a new phone"; if bob bought a new phone, he'll have verified it when he logged in, and so the warning doesn't show up.
Anyone who actually uses Matrix will be familiar with the fact that it's pretty rare to see a big red X on a user who you've verified, and when it happens, you go ping them to ask wtf is going on - much like you'd ping the webmaster of a site whose TLS certificate is bad. This is why the Matrix community is not up in arms about this "vulnerability" - it is literally following the intended design, right from the point that we announced verification back in https://element.io/blog/e2e-encryption-by-default-cross-sign....
Now, this design can absolutely be improved on - at the least, we could go back to freezing the room whenever there's an unverified device, forcing the users to decide how to flush out the old device. Or we could switch to TOFU, and block unverified devices by default. But we've chosen to prioritise migrating the clients onto a single E2EE codebase (matrix-rust-sdk-crypto) first, so we do that work in a single place, rather than in quadruplicate across matrix-{js,ios,android,rust}-sdk.
A quick comment on this, we did address this in our paper:
"In environments where cross-signing and verification are enabled, adding a new unverified user adds a warning to the room to indicate that unverified devices are present. However, it is possible for a homeserver to add a verified user to rooms without changing the security properties of the room. This allows a colluding homeserver and verified user to eavesdrop on rooms not intended for them. In other words, the warning regarding unverified devices is independent to whether the device is intended to participate in the specific room. Finally we note that users may, of course, simply ignore warnings." https://nebuchadnezzar-megolm.github.io/static/paper.pdf
"In environments where cross-signing and verification are enabled, adding a new unverified user adds a warning to the room to indicate that unverified devices are present. However, it is possible for a homeserver to add a verified user to rooms without changing the security properties of the room. This allows a colluding homeserver and verified user to eavesdrop on rooms not intended for them. In other words, the warning regarding unverified devices is independent to whether the device is intended to participate in the specific room. Finally we note that users may, of course, simply ignore warnings." https://nebuchadnezzar-megolm.github.io/static/paper.pdf
> The point is that if your threat model cares about interception, you have to verify the identity of users out of band - same as Signal or WhatsApp or whatever.
I’ve read your blog posts and this comment, congratulations it seems to have satisfied most people. Howerver it is NOT the same as Signal. Signal servers cannot just add a device to a group chat.
I would challenge you to get one reputable cryptographer to back what you’re claiming about these vulnerabilities and your proposed fixes.
To me Matrix isn’t secure, the organizations responses to these disclosures has been poor and the “fixes” weak.
I’ve read your blog posts and this comment, congratulations it seems to have satisfied most people. Howerver it is NOT the same as Signal. Signal servers cannot just add a device to a group chat.
I would challenge you to get one reputable cryptographer to back what you’re claiming about these vulnerabilities and your proposed fixes.
To me Matrix isn’t secure, the organizations responses to these disclosures has been poor and the “fixes” weak.
You are completely misinterpreting my quote, which makes me question whether you are acting in good faith.
Totally agreed that Signal servers cannot just add a device to a group chat.
What I saying was: in any system, you have to verify users for security in general. Having verified users in Matrix, you then get a massive red warning if an unverified device is added to their accounts. Given we have cross-signing (i.e. users are heavily encouraged to verify their own devices when they log in), you can be sure that such unverified devices are malicious and take appropriate action.
The obvious thing we could do is to go one step further (as we used to, until we backed it out in https://github.com/matrix-org/matrix-react-sdk/pull/3837) and stop messages from flowing until the unverified device has been dealt with. Even better would be to make group membership controlled by the clients, so the server can't add devices at all. And we're working on this, as part of shifting the implementations over to the audited matrix-rust-sdk-crypto implementation to avoid having to solve the problem in quadruplicate.
> I would challenge you to get one reputable cryptographer to back what you’re claiming about these vulnerabilities and your proposed fixes.
Hopefully someone will pop up here and confirm that I'm not talking shit :) Failing that, you'll have to wait for the next Least Authority audit - we have another independent public audit queued once this wave of work finishes to address the "To me Matrix isn't secure" polemicists. You can see the last one (on the crypto layer, rather than the group membership layer) at https://matrix.org/blog/2022/05/16/independent-public-audit-... fwiw.
Totally agreed that Signal servers cannot just add a device to a group chat.
What I saying was: in any system, you have to verify users for security in general. Having verified users in Matrix, you then get a massive red warning if an unverified device is added to their accounts. Given we have cross-signing (i.e. users are heavily encouraged to verify their own devices when they log in), you can be sure that such unverified devices are malicious and take appropriate action.
The obvious thing we could do is to go one step further (as we used to, until we backed it out in https://github.com/matrix-org/matrix-react-sdk/pull/3837) and stop messages from flowing until the unverified device has been dealt with. Even better would be to make group membership controlled by the clients, so the server can't add devices at all. And we're working on this, as part of shifting the implementations over to the audited matrix-rust-sdk-crypto implementation to avoid having to solve the problem in quadruplicate.
> I would challenge you to get one reputable cryptographer to back what you’re claiming about these vulnerabilities and your proposed fixes.
Hopefully someone will pop up here and confirm that I'm not talking shit :) Failing that, you'll have to wait for the next Least Authority audit - we have another independent public audit queued once this wave of work finishes to address the "To me Matrix isn't secure" polemicists. You can see the last one (on the crypto layer, rather than the group membership layer) at https://matrix.org/blog/2022/05/16/independent-public-audit-... fwiw.
It’s encouraging to hear that you’re getting an audit of the new approach.
Reading over the new design doc for authenticating membership events, and the Github comments, it feels like this is a case for some sort of model checking or automated theorem proving. Manually verifying that the new system does everything we want seems… tough.
Reading over the new design doc for authenticating membership events, and the Github comments, it feels like this is a case for some sort of model checking or automated theorem proving. Manually verifying that the new system does everything we want seems… tough.
Here I'll point out that Matrix had audits commissioned prior to this research as well. Audits are a good thing, but one reason the previous audits didn't hit on this stuff is that the scope of the audit was sharply limited.
Totally agreed. We didn’t have the $ to do more than libolm at first, and then we did vodozemac in May. That one was the first of 4 planned audits, the rest of which go up the rest of the stack (respectively matrix-rust-sdk-crypto, matrix-rust-sdk, and then end-to-end across the whole stack). It is very frustrating we couldn’t do the rest of the stack sooner - and this hopefully explains why we are consolidating on matrix-rust-sdk prior to getting it audited.
Ironically, the drama over this paper is now putting funding for the other audits at risk, however - as who wants to fund a project with a bunch of loud infosec folks declaring it shit?
Ironically, the drama over this paper is now putting funding for the other audits at risk, however - as who wants to fund a project with a bunch of loud infosec folks declaring it shit?
> Ironically, the drama over this paper is now putting funding for the other audits at risk, however - as who wants to fund a project with a bunch of loud infosec folks declaring it shit?
I'm not familiar with how the funding here works - can you describe the process by which audits would be abandoned as a result of internet commentary? Who is threatening to withhold funding for future audits? From my outsider's perspective, that would seem like _incredibly_ poor decision-making on behalf of the Matrix folks.
I'm not familiar with how the funding here works - can you describe the process by which audits would be abandoned as a result of internet commentary? Who is threatening to withhold funding for future audits? From my outsider's perspective, that would seem like _incredibly_ poor decision-making on behalf of the Matrix folks.
The process is:
* Audits cost $$$K
* The Matrix project doesn’t have pots of money sitting around to spend on audits. We get around $8K/month of donations on Patreon, which currently doesn’t even cover the running costs of matrix.org.
* Therefore, to get an audit done, we need to find a someone who is so excited about Matrix that they’ll fund it. For instance, the most recent audit was funded by Gematik, the German healthcare interoperability agency.
* However, the reason that folks like this get excited about Matrix is because they want a secure decentralised open communication platform. If the perception of Matrix shifts that its security is “killed dead” or other such hyperbole due to the infosec community reacting to the overclaims in the paper, then it obviously undermines that interest in Matrix. Who wants to use a protocol whose security is declared dead by cryptographers? And so who would want burn money funding audits?
This may sound dramatic, but unfortunately it’s really how it works. Just as academic papers rely on presenting the most dramatic interpretation to get attention and boost their visibility and help them get funding… similarly, open source projects get disproportionately harmed by dramatic overclaims.
* Audits cost $$$K
* The Matrix project doesn’t have pots of money sitting around to spend on audits. We get around $8K/month of donations on Patreon, which currently doesn’t even cover the running costs of matrix.org.
* Therefore, to get an audit done, we need to find a someone who is so excited about Matrix that they’ll fund it. For instance, the most recent audit was funded by Gematik, the German healthcare interoperability agency.
* However, the reason that folks like this get excited about Matrix is because they want a secure decentralised open communication platform. If the perception of Matrix shifts that its security is “killed dead” or other such hyperbole due to the infosec community reacting to the overclaims in the paper, then it obviously undermines that interest in Matrix. Who wants to use a protocol whose security is declared dead by cryptographers? And so who would want burn money funding audits?
This may sound dramatic, but unfortunately it’s really how it works. Just as academic papers rely on presenting the most dramatic interpretation to get attention and boost their visibility and help them get funding… similarly, open source projects get disproportionately harmed by dramatic overclaims.
It would behoove you to stop saying that the paper "overclaims" things. Maybe you believe I've "overclaimed" things, by saying that the paper killed your protocol as dead as TLS 1.0. I stand by that argument, but the paper's authors made no such claim. It's a dry, detailed, factual paper that just happens to rattle off a bunch of vulnerabilities both in your protocol and in Element's implementation of it.
Thank you for the clarification! Appreciate the candor here re: Element not being able to afford audits on its own. I get now why you might perceive commentary about security research as an existential threat.
For whatever it's worth, the specific thing you're doing with calling the discussion hyperbole and "overclaims" makes it harder for me to take you seriously.
For whatever it's worth, the specific thing you're doing with calling the discussion hyperbole and "overclaims" makes it harder for me to take you seriously.
Element is a client, matrix is a protocol
I don't really know where you get off on telling people you don't take them seriously
I don't really know where you get off on telling people you don't take them seriously
What is the cost of a comprehensive audit?
Can't Element (the company) fund audits?
Element doesn't have the $, thanks to footing the bill for most (90%+) of the core Matrix work on behalf of the rest of the Matrix ecosystem.
Element is probably already footing the bill for the main matrix.org server + they really need to improve their clients, and that is from a users perspective more important than a security audit.
[deleted]
the paper and this design decision by Matrix teams has recently been discussed at length in an SCW podcast (paging Thomas H. Ptacek). One of my fav episodes yet. Very sobering unfortunately.
https://securitycryptographywhatever.buzzsprout.com/1822302/...
https://securitycryptographywhatever.buzzsprout.com/1822302/...
All the pointing-and-laughing derision on the podcast seemed pretty toxic, tbh. Rather than all the "oh look how stupid Matrix are" schtick, it might have been even more interesting and informative (and less obnoxious) to get the other viewpoint and understand why we don't consider server-controlled group membership to be catastrophic in practice... as per my explanations elsewhere on the thread.
Honestly, this whole thing shows the infosec community at its worst: optimising for sensationalism/drama/press-coverage over constructive criticism and research. And it's particularly grating when the target is a mission-driven non-profit FOSS project, rather than a bungling megacorp vendor or whatever. Meanwhile things like OpenSSL RCEs or even Signal RCEs like https://thehackerblog.com/i-too-like-to-live-dangerously-acc... fly past without the researchers doing the podcast circuit(!)
Honestly, this whole thing shows the infosec community at its worst: optimising for sensationalism/drama/press-coverage over constructive criticism and research. And it's particularly grating when the target is a mission-driven non-profit FOSS project, rather than a bungling megacorp vendor or whatever. Meanwhile things like OpenSSL RCEs or even Signal RCEs like https://thehackerblog.com/i-too-like-to-live-dangerously-acc... fly past without the researchers doing the podcast circuit(!)
By all means, jump on an episode with us, and give us the other side.
We're offensive cryptography (in the "offense" vs "defense") people, and have a warm, effusive enthusiasm for offensive research results. It stings to hear enthusiasm about attack research that impacts your project, but that's not the intent, of course. You'd hear exactly the same tone if we were talking about some hypothetical system.
Meanwhile, I can't disagree more strongly with your last paragraph. This is a sensational result. It's the most impactful result ever generated against a secure messaging protocol. It deserves whatever attention it can get. To date, I think the Matrix project has been quite effective at diverting attention away from the results.
I think you'll find that even non-event OpenSSL vulnerabilities get multiple bites at the HN front page. Every serious OpenSSL vulnerability in the last 10 years has gotten vastly more attention than this research.
We do this podcast under our own names, with our own professional reputations attached, and we should all be able to at least agree that we've got a lot invested in those reputations. If we record an episode with the Matrix team giving their side and treat you unfairly, people will hear it, and that will reflect poorly on us. Apart from us just not being, like, monsters, our incentives are also aligned to give you a fair hearing.
Let's do an episode where you explain why this isn't as big a deal as we made it out to be! We're game.
We're offensive cryptography (in the "offense" vs "defense") people, and have a warm, effusive enthusiasm for offensive research results. It stings to hear enthusiasm about attack research that impacts your project, but that's not the intent, of course. You'd hear exactly the same tone if we were talking about some hypothetical system.
Meanwhile, I can't disagree more strongly with your last paragraph. This is a sensational result. It's the most impactful result ever generated against a secure messaging protocol. It deserves whatever attention it can get. To date, I think the Matrix project has been quite effective at diverting attention away from the results.
I think you'll find that even non-event OpenSSL vulnerabilities get multiple bites at the HN front page. Every serious OpenSSL vulnerability in the last 10 years has gotten vastly more attention than this research.
We do this podcast under our own names, with our own professional reputations attached, and we should all be able to at least agree that we've got a lot invested in those reputations. If we record an episode with the Matrix team giving their side and treat you unfairly, people will hear it, and that will reflect poorly on us. Apart from us just not being, like, monsters, our incentives are also aligned to give you a fair hearing.
Let's do an episode where you explain why this isn't as big a deal as we made it out to be! We're game.
> Let's do an episode where you explain why this isn't as big a deal as we made it out to be! We're game.
Sure, sounds like a plan. In order to actually present a balanced view and not end up with another one-sided episode like the last one, you might want to get the researchers involved again too.
And to be clear: my biggest issue with the podcast was the amount of (literal) laughing and derision and general "oh look how stupid they are" obnoxious attitude, rather than the claims of the paper. Our only point of contention with the paper is over whether server-controlled group membership is as big a disaster as you claim it to be, given you have to verify users to avoid interception anyway, at which point malicious devices are clearly flagged so clients can take evasive action (e.g. big red warnings, or refuse to encrypt messages in that room, etc.). From a purely theoretical perspective: yes, it's a bug that a server can add ghost devices at all. From a practical perspective, please show me the attack where a server or HTTPS MITM can add ghost devices to a verified user without the malicious user and room turning bright red like a TLS cert warning.
Anyway, once we've landed the TOFU and client-controlled-membership work (which is already overdue) I'd be very happy to come on the show to explain how the mitigations work, where the issues came from in the first place, and why we think the paper seriously overclaimed (which is a shame, given the actual implementation vulnerabilities were great research).
Thanks for the invite! :)
Sure, sounds like a plan. In order to actually present a balanced view and not end up with another one-sided episode like the last one, you might want to get the researchers involved again too.
And to be clear: my biggest issue with the podcast was the amount of (literal) laughing and derision and general "oh look how stupid they are" obnoxious attitude, rather than the claims of the paper. Our only point of contention with the paper is over whether server-controlled group membership is as big a disaster as you claim it to be, given you have to verify users to avoid interception anyway, at which point malicious devices are clearly flagged so clients can take evasive action (e.g. big red warnings, or refuse to encrypt messages in that room, etc.). From a purely theoretical perspective: yes, it's a bug that a server can add ghost devices at all. From a practical perspective, please show me the attack where a server or HTTPS MITM can add ghost devices to a verified user without the malicious user and room turning bright red like a TLS cert warning.
Anyway, once we've landed the TOFU and client-controlled-membership work (which is already overdue) I'd be very happy to come on the show to explain how the mitigations work, where the issues came from in the first place, and why we think the paper seriously overclaimed (which is a shame, given the actual implementation vulnerabilities were great research).
Thanks for the invite! :)
I'm absolutely rooting for you doing an episode together. please listen to some other episodes before dismissing the content because of format - they're fantastic.
> whether server-controlled group membership is as big a disaster as you claim it to be, given you have to verify users to avoid interception anyway, at which point malicious devices are clearly flagged so clients can take evasive action (e.g. big red warnings, or refuse to encrypt messages in that room, etc.).
I really would love to see this addressed: the UE of crypto. In 2022 we should absolutely refrain from leaving the decision to the user w.r.t if it is safe or trustworthy. Users suck. Don't trust users to look at warnings unless you're intention is to cater to only those of us who still have a GPG FPR in their ~/.signature
It. Does. Not. Work.
"Web of Trust" was a great idea but failed to scale (when was the last time you received a gpg encrypted mail from anyone).
Signal served us well until SGX.fail (https://sgx.fail), and it's why something like Matrix deserves to succeed.
Systems get better under pressure (when questioned) so I really hope y'all get a chance to talk.
> whether server-controlled group membership is as big a disaster as you claim it to be, given you have to verify users to avoid interception anyway, at which point malicious devices are clearly flagged so clients can take evasive action (e.g. big red warnings, or refuse to encrypt messages in that room, etc.).
I really would love to see this addressed: the UE of crypto. In 2022 we should absolutely refrain from leaving the decision to the user w.r.t if it is safe or trustworthy. Users suck. Don't trust users to look at warnings unless you're intention is to cater to only those of us who still have a GPG FPR in their ~/.signature
It. Does. Not. Work.
"Web of Trust" was a great idea but failed to scale (when was the last time you received a gpg encrypted mail from anyone).
Signal served us well until SGX.fail (https://sgx.fail), and it's why something like Matrix deserves to succeed.
Systems get better under pressure (when questioned) so I really hope y'all get a chance to talk.
> In 2022 we should absolutely refrain from leaving the decision to the user w.r.t if it is safe or trustworthy. Users suck. Don't trust users to look at warnings
Yup, totally. Which is why we are addressing it. The current behaviour dates back to 2016, and reflects the transition from plaintext to e2ee matrix which happened between then and now - much as TLS browser warnings have evolved in the same timeframe, and eventually being replaced by HSTS and friends. It doesn’t mean that the previous behaviour is catastrophic though - just as browser warning semantics doesn’t kill TLS.
Yup, totally. Which is why we are addressing it. The current behaviour dates back to 2016, and reflects the transition from plaintext to e2ee matrix which happened between then and now - much as TLS browser warnings have evolved in the same timeframe, and eventually being replaced by HSTS and friends. It doesn’t mean that the previous behaviour is catastrophic though - just as browser warning semantics doesn’t kill TLS.
This post was likely motivated by a current comment thread re this vulnerability, https://news.ycombinator.com/item?id=33009721, see there for some information on its impact.
Also discussed in https://news.ycombinator.com/item?id=33009721 two months ago (42 points, 37 comments) with the participation of the researchers.
Also discussed in https://news.ycombinator.com/item?id=33009721 two months ago (42 points, 37 comments) with the participation of the researchers.
I posted it after seeing it on Twitter, it was presented at an event earlier in the week: https://mobile.twitter.com/claucece/status/15999293370079191...
Any attempt to change the IV (initialization vector) in a counter based block cipher mode entirely breaks decryption. So I am not sure why the "IND-CCA" attack would need to be fixed. It is like claiming that a system is broken because an attacker can block message delivery.
It only entirely breaks decryption if the ciphertext is authenticated. In something like bare CBC mode it only breaks the decryption of the next block, all later blocks are unaltered.
Usually cryptographers consider anything less secure than IND-CCA3[1] Secure (authenticated INDistinguishability under adaptive Chosen Ciphertext Attack) to be "insecure" in the most general sense of security. The system must defend against forged messages, not simply keep the contents of messages confidential. Accepting forged messages almost always leads to some way to break confidentiality eventually.
[1] https://crypto.stackexchange.com/a/26738/17861
Usually cryptographers consider anything less secure than IND-CCA3[1] Secure (authenticated INDistinguishability under adaptive Chosen Ciphertext Attack) to be "insecure" in the most general sense of security. The system must defend against forged messages, not simply keep the contents of messages confidential. Accepting forged messages almost always leads to some way to break confidentiality eventually.
[1] https://crypto.stackexchange.com/a/26738/17861
I think you might mean IND-CCA2 here. IND-CCA3 doesn't seem to have gotten a lot of traction as a "notion".
At any rate, once you have a deployed a system, theoretical notions of security are much less important. You then have to show an actual weakness if you want to convince someone to change something.
At any rate, once you have a deployed a system, theoretical notions of security are much less important. You then have to show an actual weakness if you want to convince someone to change something.
You're talking to an HN user with a hobbyhorse about authenticated encryption being, at least sometimes, a bad thing; they reached this opinion after being pressed on the weaknesses of PGP's authenticator.
There's no actual debate here: the authors of the paper call the attack they're referring to out as a design flaw, but not an exploitable weakness. Presumably, the Matrix team will fix this as soon as it's tractable; I don't think any involved cryptography engineer is sticking up for the design.
There's no actual debate here: the authors of the paper call the attack they're referring to out as a design flaw, but not an exploitable weakness. Presumably, the Matrix team will fix this as soon as it's tractable; I don't think any involved cryptography engineer is sticking up for the design.
>You're talking to an HN user with a hobbyhorse about authenticated encryption being, at least sometimes, a bad thing...
This is misleading as stated.
>they reached this opinion after being pressed on the weaknesses of PGP's authenticator.
This is just confusing to me. At any rate, the OpenPGP standard has a robust authenticated encryption construct in the form of the MDC (modification detection code) combined with OpenPGP's improved version of CFB (cipher feed back). Not that that has anything to do with the subject at hand. We are talking about Matrix.
This is misleading as stated.
>they reached this opinion after being pressed on the weaknesses of PGP's authenticator.
This is just confusing to me. At any rate, the OpenPGP standard has a robust authenticated encryption construct in the form of the MDC (modification detection code) combined with OpenPGP's improved version of CFB (cipher feed back). Not that that has anything to do with the subject at hand. We are talking about Matrix.
I mean, I guess I could back off the word "hobbyhorse" (I describe a bunch of my own interests that way, for what it's worth), but otherwise: I can support that argument with evidence, easily.
We explain how this works in Appendix A of https://nebuchadnezzar-megolm.github.io/static/paper.pdf but it's also a nice little exercise to work out how this breaks confidentiality. TL;DR: Yes, the plaintext coming out is not what you'd expect ("breaks decryption") but in a predictable way.
> It is common among secure messengers to require out-of-band verification to protect against active mallory-in-the-middle attacks.
What is Mallory-in-the-middle?
EDIT: It's the same as man-in-the-middle. Author's explain this when they first mention MiTM.
What is Mallory-in-the-middle?
EDIT: It's the same as man-in-the-middle. Author's explain this when they first mention MiTM.
Cryptography parlance for a man-in-the middle adversary.
https://en.wikipedia.org/wiki/Alice_and_Bob might be of interest :)
https://en.wikipedia.org/wiki/Alice_and_Bob might be of interest :)
I was sure it's something else, never heard of this being a standard term. Google search gives me only movie characters, "name meaning" pages, and a project called "Mallory in the middle" that implements some specific man-in-the-middle attack.
I guess it's another case of those "raising awareness" changes, that is supposed not to cost anything, but just made me spend like 4 min confusedly googling what the new term means.
I guess it's another case of those "raising awareness" changes, that is supposed not to cost anything, but just made me spend like 4 min confusedly googling what the new term means.
I released a MiTM tool over a decade ago at BlackHat named Mallory. It is the common name for a malicious actor in between Alice and Bob in cryptography explanation.
It has to do with the history of using names like Alice and Bob in cryptography, and nothing to do within your suggested reason.
You mean calling the adversary Mallory? Yes, this is standard. The term mallory-in-the-middle is not, as you can confirm with one Google search. There's barely anyone using this term, and nobody was using it 4 years ago.
At first, I thought that Mallory-in-the-middle was some special type of man-in-the-middle attack. In crypto, Mallory is a very specific type of adversary (active one, I think).
At first, I thought that Mallory-in-the-middle was some special type of man-in-the-middle attack. In crypto, Mallory is a very specific type of adversary (active one, I think).
Mallory is used to refer to active network exploitation (as opposed to Eve, who is passive). "Mallory-in-the-middle" is a great term that actually makes the attacker capabilities more clear and should already be understood by people with relevant context. The default "let's remove gendered terms" approach would be "person-in-the-middle."
Most MITM attacks that we care about are active attacks (hence Mallory.) An eavesdropper-in-the-middle attack would just be the standard attack setting, not an MITM. For those who are experts the term is “MITM” and I don’t care what the first M stands for.
While Mallory-in-the-middle is certainly less-common as a term, Mallory is most strongly associated with active-MitM examples, and vice-versa.
> There's barely anyone using this term, and nobody was using it 4 years ago.
At my employer (security consultancy in Germany), we switched ~two weeks ago from "man" in the middle to "machine" in the middle as expansion for the MITM acronym. Mallory is also a good option, although more known to cryptographers than our mainly developer audience (who might have more of an idea what a machine is than a Mallory). It's all not perfect but we're figuring this out. Yes, neutral gender writing is indeed relatively new and won't be much on web searches. Apparently some others use AiTM for attacker in the middle (yes, with that capitalization), which most people hated and voted against (because capitalizing the The but not the in looks dumb and, also, everyone already knows mitm so that change harms readability even more). It'll be a while before the community settles on something and "man" is not the most commonly known one. Bear with us until then!
At my employer (security consultancy in Germany), we switched ~two weeks ago from "man" in the middle to "machine" in the middle as expansion for the MITM acronym. Mallory is also a good option, although more known to cryptographers than our mainly developer audience (who might have more of an idea what a machine is than a Mallory). It's all not perfect but we're figuring this out. Yes, neutral gender writing is indeed relatively new and won't be much on web searches. Apparently some others use AiTM for attacker in the middle (yes, with that capitalization), which most people hated and voted against (because capitalizing the The but not the in looks dumb and, also, everyone already knows mitm so that change harms readability even more). It'll be a while before the community settles on something and "man" is not the most commonly known one. Bear with us until then!
It's hard not to write this entire exercise off as a dumb game of woke semantics.
Especially in Germany, albeit with an outsider's perspective, I would say it's very clear how relevant it is how you speak of persons. There is no commonly accepted 'singular they' and e.g. 'teacher' is always male (you'd have to say 'teacheress' or 'teacherin', not sure how to translate it, and so what people do is say both every time they refer to any teacher/in).
When always having to gender every word, not being inclusive has a measurable effect. There are enough studies that show the effects of listing genders alongside job listings that are typical/historical male or female jobs, also in other languages with less gendering. English is a lot better as a language, in my opinion, but still if you say "he" when referring to the aforementioned "doctor" when, really, it could be a doctor of either gender using the patient portal, you are still reinforcing a bias.
I don't think it's unnecessary to include the other half of the population in general writing, even if nobody has studied the effect of a "man in the middle" specifically. There's enough evidence elsewhere so that we might as well just switch things over at hardly any cost of change and no cost at all afterwards.
When always having to gender every word, not being inclusive has a measurable effect. There are enough studies that show the effects of listing genders alongside job listings that are typical/historical male or female jobs, also in other languages with less gendering. English is a lot better as a language, in my opinion, but still if you say "he" when referring to the aforementioned "doctor" when, really, it could be a doctor of either gender using the patient portal, you are still reinforcing a bias.
I don't think it's unnecessary to include the other half of the population in general writing, even if nobody has studied the effect of a "man in the middle" specifically. There's enough evidence elsewhere so that we might as well just switch things over at hardly any cost of change and no cost at all afterwards.
The change of terms itself, or the people getting so riled up about it?
> which most people hated and voted against
Was there voting about these things? Who got invited to vote?
Was there voting about these things? Who got invited to vote?
People just speak out for or against things in the chat. Manner of speaking, not an official ballot voting system.
And to be clear, nobody was against being more gender neutral, just in favor of machine in the middle over attacker in the middle.
And to be clear, nobody was against being more gender neutral, just in favor of machine in the middle over attacker in the middle.
I'm not saying this way of gathering people's opinions is completely useless, but it has big flaws. Being against this sort of feminist initiatives can get you labeled all sorts of things in the best case, and cancelled in the worst case.
It's like making a poll in Russia about whether citizens support the invasion of Ukraine or not, when saying you don't like it is a criminal offense that can get you in jail. "I just went out and asked some people on the streets of Moscow whether they support bombing of Ukraine, nobody said no while a couple of them said yes, so they must really like that."
It's like making a poll in Russia about whether citizens support the invasion of Ukraine or not, when saying you don't like it is a criminal offense that can get you in jail. "I just went out and asked some people on the streets of Moscow whether they support bombing of Ukraine, nobody said no while a couple of them said yes, so they must really like that."
This change wasn't an organised discussion but casually came up while writing a report: the writer changed the acronyms template text (for this report) from MITM to AiTM, he let the team know and asked whether the upstream (company-wide) template should be changed also. That sparked alternative suggestions like Machine instead of Attacker and we ended up going with that. It wasn't intended to be formal and vote-like. I'm not sure setting up an anonymous vote (on some third party system to avoid being able to see server logs) is feasible every time something like this comes up.
How would you say we could do better? I'm definitely open for ideas if there are feasible methods. (And if it's not a "feasible" method for this one-off, then it might still be a good thing for more general / organised opinion gathering.)
How would you say we could do better? I'm definitely open for ideas if there are feasible methods. (And if it's not a "feasible" method for this one-off, then it might still be a good thing for more general / organised opinion gathering.)
[deleted]
Most of these attacks are about user identity. I would be interested to know if fixing them broke usability as is so often the case.
The identity issue is basically the issue in end to end encrypted messaging. Identity gets a lot harder when you have more than two participants in such a chat.
The identity issue is basically the issue in end to end encrypted messaging. Identity gets a lot harder when you have more than two participants in such a chat.
I think this is the most impactful set of cryptographic findings ever presented against any secure messaging system. I don't think the authors agree with me, but I'll say it anyways: this is a landmark paper.
Here are the findings:
1. The Matrix protocol, as designed at the time, gave servers control over both group membership and over device ownership. Because all Matrix messages in practice are group messages, this means that servers control all the keys, and can decrypt arbitrary messages. They can do that by surreptitiously injecting "users" into groups, whereupon the members of the group will send that "user" their group key, or by surreptitiously adding devices to user accounts.
2. The out-of-band key verification primarily used by Matrix (there are several, this is I think the primary one), SAS, was cryptographically broken. There are a variety of long-term keys managed for each Matrix account; in the SAS subprotocol, 2 of those keys are used without domain separation (that is, no identifier is mixed into the protocol to mathematically establish "this key should only be valid if it was generated in the context of this use"). As a result, servers can spoof SAS completion for users by cleverly arranging identifiers for those users.
3. Servers can spoof user messages, simply by slapping another user's identity on "forwarded room key" messages. This produces a warning, and is a building-block attack.
4. Matrix uses two different cryptographic messaging protocols, Olm and Megolm. Olm is a point-to-point cryptographic ratchet (think classic Signal), and Megolm is the group protocol. Matrix uses Olm for housekeeping tasks and Megolm for messaging. Both protocols keep their own cryptographic state. You can confuse a Matrix target by unexpectedly mixing Olm and Megolm messages, in tandem with the previous building-block attack, to spoof user identities without any warnings (you do this by spoofing open a Megolm "channel", which is like a messaging leg of a Matrix group).
5. Matrix has an encrypted backup subprotocol so that the server can escrow keys between devices (that is, Matrix provides secure encrypted storage of message state for users, ostensibly arranged so the server can't read any of it). The previous reliable spoofing attack can be used by the server to break it, and recover any user's encrypted state: you spoof a user to themselves and trick them into setting a backup key that you control.
Some obvious takeaways here:
* In a group secure messaging protocol, group membership is key management. If group membership is insecure, the system is insecure. Matrix isn't the first secure messenger to blow up over group membership.
* All modern secure messengers are complex. If you look at Signal's design, you'll see cryptographic construction on top of cryptographic construction. But a sound protocol is restrained. The pieces all fit together organically. Matrix, on the other hand, sprawls. There is a tremendous amount of stuff going on, and it's difficult to reason about.
* The Matrix team is responding to these vulnerabilities by altering the protocol. That's good. But the initial response given to the researchers regarding group membership was that they were going to accept the risk(!) of server-controlled group messaging, and concentrate on ensuring warnings were reliably given to users. Group membership is key management. By the time you're reading a warning, an attacker is decrypting messages. To shoplift the words of a great sage, the god-damned plane has crashed into the mountain.
Here are the findings:
1. The Matrix protocol, as designed at the time, gave servers control over both group membership and over device ownership. Because all Matrix messages in practice are group messages, this means that servers control all the keys, and can decrypt arbitrary messages. They can do that by surreptitiously injecting "users" into groups, whereupon the members of the group will send that "user" their group key, or by surreptitiously adding devices to user accounts.
2. The out-of-band key verification primarily used by Matrix (there are several, this is I think the primary one), SAS, was cryptographically broken. There are a variety of long-term keys managed for each Matrix account; in the SAS subprotocol, 2 of those keys are used without domain separation (that is, no identifier is mixed into the protocol to mathematically establish "this key should only be valid if it was generated in the context of this use"). As a result, servers can spoof SAS completion for users by cleverly arranging identifiers for those users.
3. Servers can spoof user messages, simply by slapping another user's identity on "forwarded room key" messages. This produces a warning, and is a building-block attack.
4. Matrix uses two different cryptographic messaging protocols, Olm and Megolm. Olm is a point-to-point cryptographic ratchet (think classic Signal), and Megolm is the group protocol. Matrix uses Olm for housekeeping tasks and Megolm for messaging. Both protocols keep their own cryptographic state. You can confuse a Matrix target by unexpectedly mixing Olm and Megolm messages, in tandem with the previous building-block attack, to spoof user identities without any warnings (you do this by spoofing open a Megolm "channel", which is like a messaging leg of a Matrix group).
5. Matrix has an encrypted backup subprotocol so that the server can escrow keys between devices (that is, Matrix provides secure encrypted storage of message state for users, ostensibly arranged so the server can't read any of it). The previous reliable spoofing attack can be used by the server to break it, and recover any user's encrypted state: you spoof a user to themselves and trick them into setting a backup key that you control.
Some obvious takeaways here:
* In a group secure messaging protocol, group membership is key management. If group membership is insecure, the system is insecure. Matrix isn't the first secure messenger to blow up over group membership.
* All modern secure messengers are complex. If you look at Signal's design, you'll see cryptographic construction on top of cryptographic construction. But a sound protocol is restrained. The pieces all fit together organically. Matrix, on the other hand, sprawls. There is a tremendous amount of stuff going on, and it's difficult to reason about.
* The Matrix team is responding to these vulnerabilities by altering the protocol. That's good. But the initial response given to the researchers regarding group membership was that they were going to accept the risk(!) of server-controlled group messaging, and concentrate on ensuring warnings were reliably given to users. Group membership is key management. By the time you're reading a warning, an attacker is decrypting messages. To shoplift the words of a great sage, the god-damned plane has crashed into the mountain.
For the sake of accuracy, it’s worth pointing out that points 2 through 5 were implementation bugs resolved in https://matrix.org/blog/2022/09/28/upgrade-now-to-address-en.... They are not current attacks, despite the present tense used to describe them in the parent post.
re: implementation bugs: Almost, but not quite. See https://nebuchadnezzar-megolm.github.io/#anticipated-questio...
Also note that in the review of the ecosystem the Matrix developers, i.e you :), also discovered further clients vulnerable to variants of attack #3 and assigned CVE-2022-39252, CVE-2022-39254 and CVE-2022-39264.
While I'm here, yep those seem fixed also as far as we can tell: https://nebuchadnezzar-megolm.github.io/#remediesfixes
Also note that in the review of the ecosystem the Matrix developers, i.e you :), also discovered further clients vulnerable to variants of attack #3 and assigned CVE-2022-39252, CVE-2022-39254 and CVE-2022-39264.
While I'm here, yep those seem fixed also as far as we can tell: https://nebuchadnezzar-megolm.github.io/#remediesfixes
> the god-damned plane has crashed into the mountain
I've got information, man— new shit has come to light
I've got information, man— new shit has come to light
does this "vulnerability" disclosure and its ongoing fix support the idea that more people are looking at the code and finding faults, before they get exploited in the wild, making the software "better"? as opposed to blindly claiming "unhackable" argument, the software is getting better?
It’s definitely making the software better.
See the MSC3917 document linked by Arathorn. They have put a lot of effort into thinking about the threat models and how to address each them.
Is it perfect? Well, no. But it’s a hard problem and they are making meaningful progress.
See the MSC3917 document linked by Arathorn. They have put a lot of effort into thinking about the threat models and how to address each them.
Is it perfect? Well, no. But it’s a hard problem and they are making meaningful progress.
Nothing is unhackable but at least you have the right to patch open source projects.
Properly used formal verification, could make unhackable software, but expensive, because of this used rarely.
For example, I know people, who made formal verification of their soft for power plants.
For example, I know people, who made formal verification of their soft for power plants.
The only pending work is switching to TOFU (trust on first use) and client-controlled room membership. Currently users get warned if a malicious device or user gets added to a room by a malicious server (assuming users in the room are verified). However, rather than warning, we could block it outright - but this is nontrivial as it means clients have to independently replicate the group membership semantics the server currently handles, which are complicated in a decentralised environment.
https://github.com/matrix-org/matrix-spec-proposals/blob/fay... is the work ongoing to shift membership to be controlled clientside, and https://github.com/matrix-org/matrix-spec-proposals/blob/fay... is the work ongoing to shift to TOFU.
Meanwhile, this work is blocked behind switching to matrix-rust-sdk-crypto across Element on Web, iOS and Android, so we only fix this in one (audited) place - and can also build on the newly audited vodozemac implementation of Matrix’s encryption: https://matrix.org/blog/2022/05/16/independent-public-audit-.... This work is going well though - I for one have been dogfooding ElementR (Element with rust-sdk-crypto) on iOS as my daily driver for the last week, and we should be releasing it shortly.