### Summary
Due to a gap in validation of federated content in the affected Mastodon versions, attackers can craft payloads that impersonate remote federated accounts as-seen-from the affected s...
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?
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.
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, consider asking its admins to do so. 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.
But the commit to fix insufficient origin validation is already visible right there in the repo?
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.
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, consider asking its admins to do so. 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.
Nice work :)
deleted by creator
not the person you’re replying to but yes, anyone on an unpatched server is vulnerable