Update: there are additional reported vulnerabilities that I have been made aware of.
These have been shared with the Piefed Dev but no fixes yet in place.
Given this knowledge and the fact these exploits could be used to target vulnerable users and potentially access account data, I feel it is sensible to keep the instance offline until further fixes are in place.
Makes sense, thank you!
honestly i started using piefed because A) there's a .zip instance; and B) it's easier to follow people
given these security problems on top of the main dev's drama, i'll probably just delete my piefed and move back to lemmy
I'm on my phone so I can't review the issues, but I'm guessing they're mostly about the web interface. I would just not expose that to the world, only expose the necessary federation API endpoints.
it's not even that, but the dev rimu banning people and people getting mad about it.. i'll stick with demigodrick, lemmy, and .zip. don't need any of that extra crap
lemmy
the dev rimu banning people and people getting mad about it
Let's be honest, Lemmy devs are also known to be banning a lot.
If you were not using the Piefed features (personal feeds, crossposts comments consolidation, flairs, instance blocking) then going back to Lemmy makes sense.
It doesn't really matter in the end, all the communities are still available on all sides (with Mbin)
Rimu has banned then from the flagship .social instance.
Do anyone care, that the Lemmy flagship is technically .ml?
A few months ago I mentioned in a thread about Piefed there were questionable system design choices that indicated that other parts of the system should be carefully examined for how they’re handling and sanitizing input. I'm assuming someone discovered one of the places that this was actively exploitable.
From what I've seen of the code, although Python is not my specialty, it might be worth delaying reactivation until it can demonstrate that it is at least somewhat resistant to the OWASP Top 10, especially Injection.
Irresponsible disclosure is annoying, but vastly better than discovery and exploitation by those who aren't going to disclose at all.
You can look at https://codeberg.org/rimu/pyfedi/releases/tag/v1.6.25 to see the changes.
Basically, the 0-day was mostly someone running an LLM and trying to discover vulnerabilities without double checking them. Most of the things reported were not applicable (mentioning functions that don’t even exist), others were not applicable but led to some tangent hardening.
Lemmy also had a SSRF vulnerability a month ago: https://github.com/LemmyNet/lemmy/security/advisories/GHSA-q537-8fr5-cw35
The raw changes are interesting but not particularly descriptive of the problem(s?) it intends to resolve, so I can't gauge whether it achieves the goal from this. The description of the version bump as simply "security improvements" doesn't help me determine if any of these changes add dedicated tests or anything else to prevent future occurrences (and I'm not traversing the repository on my phone). Additionally, the issue acknowledged via inline comment: "This will probably break PeerTube federation" is odd to omit from even the briefest changelog. In my opinion, this is not that reassuring an update.
The LLM generated report of Lemmy's vulnerability, which I note requires an entire DNS configuration to exploit, is a little ironic to point to as an authoritative source while characterizing the Piefed exploit discovery as "someone running an LLM and trying to discover vulnerabilities without double checking them".
But I don't think it's necessary or helpful to have a competitive security score-card situation between packages either - I would much prefer that each ActivityPub implementation is meaningfully improving their development lifecycle processes, especially around security risk mitigation, even if they don't go quite as far as having a formal "security posture".
You can look at https://codeberg.org/rimu/pyfedi/releases/tag/v1.6.25 to see the changes.
Basically, the 0-day was mostly someone running an LLM and trying to discover vulnerabilities without double checking them. Most of the things reported were not applicable (mentioning functions that don't even exist), others were not applicable but led to some tangent hardening.
Lemmy also had a SSRF vulnerability a month ago: https://github.com/LemmyNet/lemmy/security/advisories/GHSA-q537-8fr5-cw35
Thanks, as always, Demigodrick. I'll use my lemmy.zip alt until things are sorted.
EDIT: This has been resolved thanks to the helpful people on the matrix channel. For anyone else having problems, I just exported my lemmy profile, prettified both json files and manually moved over my blocks and subs then re-imported the modified lemmy file.
Hi there @Demigodrick@lemmy.zip , is there any way to use the piefed.zip export to import to lemmy.zip? I tried since it was mentioned in the email but it just states that the import failed when I try.
Just wondering if I can modify or remove some elements of the file so I can use it to get the blocks and subs imported from my piefed account.
Thanks!
Thank you for taking proactive measures. I hope it gets resolved soon.
Are there any information around the nature of the vulnerability or the status of a fix?
GOAT
Most admins would stick their head in the sand. Thank you!
Thank you!
Appreciate the email on this. I don't think I got an email from Piefed.social either. Heck I don't remember getting any from Lemmy.ca for Lemmy downtime. But perhaps they haven't ran into a similar situation.
Thanks for the heads up.
Is there a timeline on when piefed.zip will come back online, a fix has now been released and piefed.social and piefed.blahaj.zone seem to have come back online
It's Saturday, I would give the .zip team some time
I understand, apologies if I was being rude
No worries!
lemmy.zip annoucements
The same rules as the main instance apply here.