A new security fund opens up to help protect the fediverse
-
Yeah!
I asked here about that and was told there's not enough of us here. Meh.
Funny how that works. Wonder if not mentioning it will help remedy that?
-
- 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.
It has everything to do with ActivityPub since if you follow that protocol strictly you will cause this behavior. It still doesn't change that Dansup was told that this caused Bad Things(tm) and yet he didn't follow normal procedure in how you handle it.
Vulnerabilities don't need to be buffer overflows.
/cybersec researcher
-
It has everything to do with ActivityPub since if you follow that protocol strictly you will cause this behavior. It still doesn't change that Dansup was told that this caused Bad Things(tm) and yet he didn't follow normal procedure in how you handle it.
Vulnerabilities don't need to be buffer overflows.
/cybersec researcher
It has everything to do with ActivityPub since if you follow that protocol strictly you will cause this behavior.
Absolutely not. Which part of the spec? I linked up there to quite a thorough explanation of what the spec does and doesn't dictate in this area. What part of my explanation did I get wrong?
/cybersec researcher
I do not believe you. "I'm sending things out which need to be handled carefully in a protocol-nonstandard way by the recipient server software (which could be literally anything), or else my user's private posts will be exposed. If someone talks about that situation and lets people know what's going on, that's irresponsible disclosure."
If you actually are a cybersec researcher, you are bad at your job.
-
It has everything to do with ActivityPub since if you follow that protocol strictly you will cause this behavior.
Absolutely not. Which part of the spec? I linked up there to quite a thorough explanation of what the spec does and doesn't dictate in this area. What part of my explanation did I get wrong?
/cybersec researcher
I do not believe you. "I'm sending things out which need to be handled carefully in a protocol-nonstandard way by the recipient server software (which could be literally anything), or else my user's private posts will be exposed. If someone talks about that situation and lets people know what's going on, that's irresponsible disclosure."
If you actually are a cybersec researcher, you are bad at your job.
hahahahaha
Watch and try again
I post under my real name.https://www.cve.org/CVERecord?id=CVE-2024-44754
https://www.youtube.com/watch?v=ZbKLAjPYOEg
Feel free to post less and read more.
-
hahahahaha
Watch and try again
I post under my real name.https://www.cve.org/CVERecord?id=CVE-2024-44754
https://www.youtube.com/watch?v=ZbKLAjPYOEg
Feel free to post less and read more.
Okay. What part of the spec did Pixelfed violate? Where in the spec is Mastodon's implementation of private posts justified?
-
...that will pay those who responsibly disclose security vulnerabilities that affect fediverse apps and services.
If it is straight to the project, then I'm all for it. Otherwise, it seems sus.
It is to the person who discovers the vulnerability. That's fairly normal... how would giving it to someone else motivate the result they're trying to get?
-
Okay. What part of the spec did Pixelfed violate? Where in the spec is Mastodon's implementation of private posts justified?
Read more, post less. I've said nothing about any spec violation. That's not relevant.
-
I still feel that interoperability between mastadon and Lemmy is kind of messed up. How to browse a Lemmy community through mastodon application?
-
Read more, post less. I've said nothing about any spec violation. That's not relevant.
Thatâs not relevant.
It has everything to do with ActivityPub since if you follow that protocol strictly you will cause this behavior.
That's what I was going by. I guess I could re-read this now and interpret "this behavior" as Pixelfed's side, instead of Mastodon's side as I initially read it, and decide that you are agreeing with me that Mastodon's behavior was (and is) out of spec? Do I have that right?
It still doesnât change that Dansup was told that this caused Bad Things
and yet he didnât follow normal procedure in how you handle it.It is normal procedure to fix a bug when you are notified about it.
The design flaw in Mastodon that managed to bite Pixelfed in this situation still exists. People were writing about it back in 2017 when this was all being first implemented. The idea that "normal procedure" needs to include keeping it a secret that Mastodon's "private" statuses can be exposed by any server software that doesn't handle them in the way that's expected, is 100% wrong.
I'll rephrase what I said earlier: Since you're a security researcher, and you apparently think Dan should have played into the idea of keeping it a secret that Mastodon's private statuses are not secret by obfuscating the information about how he was fixing Pixelfed to more effectively hide them, you are bad at your job. In this instance. The fault lies with how private statuses are implemented, and nothing about that needs to be kept secret as would a normal vulnerability. In fact, it is extremely harmful to let users believe that these privacy settings are anything other than vague recommendations, specifically because of the risk they will act accordingly and expose some of their private posts to the world. They should know exactly what's going on with it, and Dan accidentally failing to keep that a secret is in no way causing bad things.
-
The fediverse, also known as the open social web that includes Mastodon, Metaâs Threads, Pixelfed, and other apps (...)
Mention Lemmy for once
We are tiny in comparison to the rest of the fediverse.
-
I still feel that interoperability between mastadon and Lemmy is kind of messed up. How to browse a Lemmy community through mastodon application?
You cannot use a mastodon app as a lemmy client, but you can view lemmy communities by opening them as if they are profiles. For example, open @[email protected] and it will show up as a user, but it will be the communitiy's posts.
You can mention it in a post to forward the post to the community as well.
-
Thatâs not relevant.
It has everything to do with ActivityPub since if you follow that protocol strictly you will cause this behavior.
That's what I was going by. I guess I could re-read this now and interpret "this behavior" as Pixelfed's side, instead of Mastodon's side as I initially read it, and decide that you are agreeing with me that Mastodon's behavior was (and is) out of spec? Do I have that right?
It still doesnât change that Dansup was told that this caused Bad Things
and yet he didnât follow normal procedure in how you handle it.It is normal procedure to fix a bug when you are notified about it.
The design flaw in Mastodon that managed to bite Pixelfed in this situation still exists. People were writing about it back in 2017 when this was all being first implemented. The idea that "normal procedure" needs to include keeping it a secret that Mastodon's "private" statuses can be exposed by any server software that doesn't handle them in the way that's expected, is 100% wrong.
I'll rephrase what I said earlier: Since you're a security researcher, and you apparently think Dan should have played into the idea of keeping it a secret that Mastodon's private statuses are not secret by obfuscating the information about how he was fixing Pixelfed to more effectively hide them, you are bad at your job. In this instance. The fault lies with how private statuses are implemented, and nothing about that needs to be kept secret as would a normal vulnerability. In fact, it is extremely harmful to let users believe that these privacy settings are anything other than vague recommendations, specifically because of the risk they will act accordingly and expose some of their private posts to the world. They should know exactly what's going on with it, and Dan accidentally failing to keep that a secret is in no way causing bad things.
You have absolutely no idea what "responsible" in "responsible disclosure" means
It's completely irrelevant how Mastodon has implemented private posts when it comes to how Dansup handled the issue, knowing what the effects were.You don't, when told of a vulnerability, handle it in a way that cause harm if it can be avoided.
-
- 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.
Maybe I'm wrong, but shouldn't posts only be insecure if they're propagated to the insecure instance?
Is any private post visible to people on servers that the poster doesn't have followers on?
Could Icurlthe uri of a post thats "private" and get the post's content? -
You have absolutely no idea what "responsible" in "responsible disclosure" means
It's completely irrelevant how Mastodon has implemented private posts when it comes to how Dansup handled the issue, knowing what the effects were.You don't, when told of a vulnerability, handle it in a way that cause harm if it can be avoided.
Yeah, you said that stuff before and then you said it again. I do understand what your argument is here. I was trying a couple of different ways of explaining what I was saying in response, but it seems like it's not working. Oh well.
-
Metaâs Threads
LOL
-
Maybe I'm wrong, but shouldn't posts only be insecure if they're propagated to the insecure instance?
Is any private post visible to people on servers that the poster doesn't have followers on?
Could Icurlthe uri of a post thats "private" and get the post's content?Maybe Iâm wrong, but shouldnât posts only be insecure if theyâre propagated to the insecure instance?
"Insecure" in this case simply means any server that doesn't implement Mastodon's custom handling for "private" posts. With that definition, the answer to your question is yes. It has been mentioned by Mastodon people that this is a significant problem for the ability to actually keep these private posts private in the real world. The chance of it going wrong is small (depending on your follower count) but the potential for harm is very large. I would therefore go further, and say that it's a very bad thing that Mastodon is telling people that these posts are "private" when the mechanism which is supposed to keep them private is so unreliable.
https://github.com/mastodon/mastodon/issues/712
Is any private post visible to people on servers that the poster doesnât have followers on?
It is not. If you're sufficiently careful with approving your followers, making sure that each of them is on an instance that's going to handle private posts the way you expect, then you're probably fine.
Could I curl the uri of a post thats âprivateâ and get the postâs content?
If it's been federated to an insecure server then yes. If not then I think no.
-
- 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.
I usually agree with you, but here @[email protected] 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).
-
Maybe Iâm wrong, but shouldnât posts only be insecure if theyâre propagated to the insecure instance?
"Insecure" in this case simply means any server that doesn't implement Mastodon's custom handling for "private" posts. With that definition, the answer to your question is yes. It has been mentioned by Mastodon people that this is a significant problem for the ability to actually keep these private posts private in the real world. The chance of it going wrong is small (depending on your follower count) but the potential for harm is very large. I would therefore go further, and say that it's a very bad thing that Mastodon is telling people that these posts are "private" when the mechanism which is supposed to keep them private is so unreliable.
https://github.com/mastodon/mastodon/issues/712
Is any private post visible to people on servers that the poster doesnât have followers on?
It is not. If you're sufficiently careful with approving your followers, making sure that each of them is on an instance that's going to handle private posts the way you expect, then you're probably fine.
Could I curl the uri of a post thats âprivateâ and get the postâs content?
If it's been federated to an insecure server then yes. If not then I think no.
Mastodon really is the internet explorer of the fediverse.
In any case, I don't think its that bad. I would compare it to an email provider accidentially leaking messages. Still bad, but its not a reason to abandon email as a means of communication.
We should encrypt posts, like diaspora does. Like how we should pgp encrypt emails, but no one will.also, I just checked myself, a random "private" post I made isn't accessible over AP if I curl it unauthenticated.
Runningcurl.exe https://calckey.world/notes/a63slz8j6l -H "Accept: application/activity+json"returns nothing, but replacing the uri with a public post does show it.
An insecure server's copy of the post isn't accessible over AP, only the original post's link should return anything. -
I usually agree with you, but here @[email protected] 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).
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.
-
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.
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 ...
