A more recent issue came about when Pixelfed’s creator, Daniel Supernault made the details of a vulnerability public before server operators had a chance to update, which would have left the fediverse vulnerable to bad actors, she says. (Supernault has already apologized publicly for his handling of the issue that had affected private accounts.)

In the case of the Pixelfed issue, for instance, the Hachyderm Mastodon server, which has over 9,500 members, decided it needed to defederate (or disconnect from) other Pixelfed servers that hadn’t been updated in order to protect their users.

It is weird to spend almost half the words in this, pretending that something in Pixelfed that wasn't a problem on Pixelfed's side was. This is the weirdest "vulnerability" in the world to pick if you want to pick one to hold up extensively as an example.

[–] troed@fedia.io 9 points 1 day ago (18 children)

Regardless whether you want to pretend that not caring about Mastodon is a valid defense when implementing software using the ActivityPub protocol, that still doesn't change anything regarding how Dansup handled the disclosure of the effects it had.

[–] PhilipTheBucket@ponder.cat 9 points 1 day ago (17 children)

This is nothing to do with ActivityPub. It's to do with Mastodon's custom implementation of "private" posts.
Making it extremely clear to everyone that random server software can expose Mastodon's "private" posts is absolutely the right way to handle disclosure here. Dan didn't even try to do that, he just fixed the bug, but if he had made a big post saying "hey this is not my fault Mastodon private posts are not private, here's full explanation about what's going on" I think that would have been completely fine. This is not a "vulnerability" in the traditional sense like a buffer overflow, it's just a design flaw in Mastodon which other softwares are by convention agreeing to cater to. I think the culture of security (and the level of clue in general) in the Fediverse has wandered into territory where "let's all pretend that these posts are secure and get mad at anyone who reveals that they are not" is widely accepted now, but that doesn't make it right.

[–] Blaze@lemmy.dbzer0.com 3 points 22 hours ago (1 children)

I usually agree with you, but here @troed@fedia.io is right.

Full disclosure

With the full disclosure approach, the full details of the vulnerability are made public as soon as they are identified. This means that the full details (sometimes including exploit code) are available to attackers, often before a patch is available. The full disclosure approach is primarily used in response or organizations ignoring reported vulnerabilities, in order to put pressure on them to develop and publish a fix.

This makes the full disclosure approach very controversial, and it is seen as irresponsible by many people. Generally it should only be considered as a last resort, when all other methods have failed, or when exploit code is already publicly available.

Responsible or Coordinated Disclosure

Responsible disclosure attempts to find a reasonable middle ground between these two approaches. With responsible disclosure, the initial report is made privately, but with the full details being published once a patch has been made available (sometimes with a delay to allow more time for the patches to be installed).

https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html#full-disclosure

[–] PhilipTheBucket@ponder.cat 3 points 21 hours ago (1 children)

Hm... maybe. The exact nature of the problem in Pixelfed means that anyone with a Pixelfed account on a server which is getting private statuses can choose to follow someone who's set to "approve followers" and then read all the private statuses. I do see how that's significantly worse than just the normal lay-of-the-land of the problem, which is a little more random, and laying that out as a little roadmap to read someone else's private statuses before there's been a nice responsible length of time for things to get fixed could be seen as worsening the problem.

The point that I'm making is that anyone who's posting private statuses to Mastodon and expecting them to stay private is making a bad mistake already. The structure of the protocol is such that they can't be assured of staying private regardless of what Pixelfed did or even if Pixelfed didn't exist. They're getting federated to servers whose behavior is not assured, in a way where a conformant ActivityPub implementation can expose them. People who are posting private statuses need to understand that.

That whole blog post where the person is talking about her partner writing private statuses, and then the gut-wrenching realization that they were being exposed on Pixelfed... but then the resolution being "Pixelfed fucked up I hate Dansup now" and then continuing to post the private statuses, is wrong. That person's partner needs to stop treating their private posts on Mastodon that way. The timer for responsible disclosure started circa 2017 or whenever Mastodon decided on how to implement their private statuses. It's been and gone.

Like I say, I get the harm-reduction aspect of saying it would have been better if Dansup was a little more discreet about this particularly bad attack vector until a few more days went by for everyone to upgrade. But it hardly matters. There are still server softwares our there that are going to be exposing people's private Mastodon posts. It's just how federation between untrusted servers works. Giving people the illusion that if Dan had just been more discreet then this harm would have been reduced is lulling them into a false sense of security, in my view.

[–] troed@fedia.io 1 points 21 hours ago (1 children)

If you know of other ActivityPub servers that expose private posts the same way I suggest you make a responsible disclosure to the developers.

I don't know of any, but you claim they exist so ...

[–] PhilipTheBucket@ponder.cat 2 points 20 hours ago (1 children)

Are you hoping to restart our disagreement through sheer passive-aggressiveness? Okay, sure.

In my view, this is a Mastodon design flaw (or a user-expectation issue or whatever you want to call it.) I already said that, and you're involved in the unproductive-arguer's pastime of pretending not to understand that that's my position, and just aggressively repeatedly reframing things according to your position and hoping I'll knuckle under to it through sheer force of repetition.

I'm not super invested in trying to track down each and every software that might manage to expose the "private" statuses in this way. I just know that as things come and go there are guaranteed to be some. If you have an mbin account and Mastodon account, though, we can try a little experiment. I don't know the outcome, I'm just curious after taking a quick look down the FediDB list and a quick grep through mbin's source code. You can be the one to responsibly disclose to mbin how their ActivityPub-conforming behavior is a problem, if indeed it turns out that it is, since you seem to be extremely committed to the idea that the model of "vulnerability" needs to be applied to this particular ActivityPub-conforming behavior. Since you're a security researcher, having that as a CVE you discovered can be an achievement for you. It's all yours, you can have it.

[–] troed@fedia.io 1 points 20 hours ago (1 children)

There are still server softwares our there that are going to be exposing people's private Mastodon posts.

You could've saved yourself a lot of typing there by just admitting to claiming things you actually didn't know.

[–] PhilipTheBucket@ponder.cat 2 points 18 hours ago* (last edited 18 hours ago)

Because it is transparently obvious that it's going to happen.

If you're sending your users' private statuses to an ActivityPub server, and just hoping that it's going to choose to keep them private according to certain parameters even though that's not what the spec stays it needs to do, then you're fucking up. The fact that we know that particular instances of particular software are exposing them is a nice demonstration of the harm, a confirmation that you're fucking up when you're doing that, but it's not really needed. It is the absolutely predictable result of some basic principles of security which, as a security researcher, you should absolutely be aware of.

I've repeatedly explained this. You've repeatedly explained your position. We've both had our say. You seem addicted to the concept of "winning" the conversation and wanting to just go back and forth. In that case I would really encourage you to state your position again, and I can state mine again, and we can both have fun doing that for a while. Want to? It sounds like a productive use of both of our time. It's fun, too.

Edit: Actually, I didn't even realize you are on fedia.io when I was typing this. You can test for yourself whether mbin does this, too, by coordinating with @Irelephant@lemm.ee. Follow his user, then have him post one of those private statuses, then fetch his user profile via fedia.io from an incognito window and see whether the private statuses show up. I have no idea whether they will, but if I had to guess, I would say it's better than even odds.

load more comments (15 replies)