### 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...
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.
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.