### Summary
Due to insufficient origin validation in all Mastodon, attackers can impersonate and take over any remote account.
Every Mastodon version prior to 3.5.17 is vulnerable, as well as...
This advisory will be edited with more details on 2024/02/15, when admins have been given some time to update, as we think any amount of detail would make it very easy to come up with an exploit.
But the commit to fix insufficient origin validation is already visible right there in the repo?
The lack of details in the advisory is only a minor impediment for a malicious person who wants to figure out how to implement their own exploit for this vulnerability. Anyone can read the patch that fixes it and figure it out.
TLDR: if you run your own instance, update it ASAP. If an instance you rely on hasn’t updated yet, ask its admins to to. And if they don’t update it soon, you might want to reconsider your choice of instance.
And if they don’t update it soon, you might want to reconsider your choice of instance.
The advisory went up about 4h ago. About 3h ago, my instance admin sent out an announcement that the patch had been applied. That was before I even heard about the issue.
Indeed but I’ve seen too many incidents now where vulns are exploited long before public POCs for FOSS code. This is why major projects have a private repo they commit to and build from before they publish publicly so that fixed builds are available without source visible. It doesn’t stop actors reversing but it does show them down a day or two which is invaluable for defenders.
This isn’t possible with Ruby and Mastodon. The only way to distribute the patch is to reveal the changes to the source. FWIW, compiling the fix is still just an obfuscation method, one can still just diff the binaries and see what changed (see: reverse-engineering Windows vulnerabilities in updates).
At best, you can release it with a bunch of unrelated and obfuscating changes, but putting work into doing that is further delaying simply getting the fix released.
Indeed but we’ve observed that compiled binaries still take actors that little bit longer (~24h) before developing exploits which, when you’re trying to buy time for users to patch, is invaluable.
Hopefully we won’t see widespread exploration before patches are applied as I can imagine a lot of instances’ infrastructure isn’t architected and managed with the level of care you see from larger orgs given how many are hobbyist efforts.
Federated services don’t need negative press this early on. It’ll only serve Meta and enterprise-created and controlled services.
But the commit to fix insufficient origin validation is already visible right there in the repo?
Could you explain what you’re saying in common language?
The lack of details in the advisory is only a minor impediment for a malicious person who wants to figure out how to implement their own exploit for this vulnerability. Anyone can read the patch that fixes it and figure it out.
TLDR: if you run your own instance, update it ASAP. If an instance you rely on hasn’t updated yet, ask its admins to to. And if they don’t update it soon, you might want to reconsider your choice of instance.
@cypherpunks @pelespirit
Are you saying if our instance hasn’t yet been patched it’s a cause for concern?
The advisory went up about 4h ago. About 3h ago, my instance admin sent out an announcement that the patch had been applied. That was before I even heard about the issue.
Nice work :)
Without a published POC there’s a slightly longer window before clueless script kiddies start having a go at exploiting the vulnerability, though.
Script kiddies aren’t the first ones to take advantage of vulns, threat actors are.
That doesn’t mean you shouldn’t try to contain the blast radius.
Indeed but I’ve seen too many incidents now where vulns are exploited long before public POCs for FOSS code. This is why major projects have a private repo they commit to and build from before they publish publicly so that fixed builds are available without source visible. It doesn’t stop actors reversing but it does show them down a day or two which is invaluable for defenders.
This isn’t possible with Ruby and Mastodon. The only way to distribute the patch is to reveal the changes to the source. FWIW, compiling the fix is still just an obfuscation method, one can still just diff the binaries and see what changed (see: reverse-engineering Windows vulnerabilities in updates).
At best, you can release it with a bunch of unrelated and obfuscating changes, but putting work into doing that is further delaying simply getting the fix released.
Indeed but we’ve observed that compiled binaries still take actors that little bit longer (~24h) before developing exploits which, when you’re trying to buy time for users to patch, is invaluable.
Hopefully we won’t see widespread exploration before patches are applied as I can imagine a lot of instances’ infrastructure isn’t architected and managed with the level of care you see from larger orgs given how many are hobbyist efforts.
Federated services don’t need negative press this early on. It’ll only serve Meta and enterprise-created and controlled services.