kaniini recently posted a few things on the security of the fediverse and i've been getting the feeling they are either misunderstanding things or purposely seeding FUD into the system. And as such, I went through the technical arguments and found .. a bunch of things that seem to make no sense, based on my knowledge of how this all works:
> Software which does not support the followers-only scope can dereference the OP's followers collection in any way they wish, including interpreting it as as:Public (this is explicitly allowed by the ActivityStreams 2.0 specification, you can't even make this up)
(ignoring the fact that as:Public isn't even in the AS2 spec) Oh but you can make it up. I had to put on my detective's hat to figure out what the rabbit pulled out of their hat, because this makes no fucking sense and only if you purposely read the spec wrong this would be the case. So, here we go!!
If you have 10000 followers, having to send one POST to each inbox would be a lot of work. So instead, you can group followers by their sharedInbox and post to each sharedInbox once, and trust that the receiving server will deliver the post to all followers. But how does this interact, in any way, with the above? well. If you have a public post, it's public. So to allow for better delivery of replies, the sharedInbox can be delivered to if the post is public (aka is addressed to as:Public), with the intent that it just sits there, so the server can use it to build up e.g. a federated timeline. I cannot find a reading in which the spec suggests follower collections can be read as 'public'.
> Mitigation of this is actually incredibly easy, which makes me question why Mastodon didn't do it to begin with: simply expand the followers collection when preparing to send the message outbound.
Well. quick thought process: what if there was no sharedInbox, and you have a 10000 large follower collection? It's not like you want to put all those 10000 followers in each post. So what do you do? You just don't. You just POST the post to each user's inbox, and let the receiving server handle it. This is actually exactly as specified. Not only that, but it allows for behavior that would otherwise be impossible. For example, the bcc and cc sets in a post. Magic, no?
> She found vulnerabilities in Mastodon, Pleroma and PixelFed, as well as recently a couple of other fediverse software.
The two vulns that started the thread are... very hard to defend against, as everything is doing exactly what it was specified to do. Nothing was running out of spec, and in theory, every And a bit later, I did find a vuln that covers *all* the fediverse software except Kroeg and Mastodon. And at this point, disclosure gets, well, exponentially hard. What do I do? tbh, at this point just saying "fediverse devs please message me if you want a copy of the vuln" is the only viable option, i feel...
And, for good measure:
> LDS has a lot of problems, but I already covered them already. You can read about some of those problems by reading up on a mitigation known as Blind Key Rotation.
This seems the most FUDdy, as HTTP signatures have all these same issues: They are irrevocable, can be permanently used as proof of posting (until keys change, of course), and-- wait, i just got hold of another post from them, let's look at that too
> as for proving the content existed -- not really. it only proves you signed some headers, including a digest header. hash collision attack is a plausible defense at the hash strength chosen.
... from my view, it seems you are either suggesting SHA-256 is hash-collidable, or that you should use a hash that is provably broken already to build the digest??? this seems ... ill-advised. And even then, the chance of finding a hash collision that changes /just/ the content of the post in such a way that it changes the entire meaning or even just replaces the content is very very very very very very small.