Any authenticated user may obtain private message details from other users on the same instance
github.com
### Summary Users can report private messages, even when they're neither sender nor recipient of the message. The API response to creating a private message report contains the private message it...

The full description of the bug is in the linked issue above, but the short version is:

Our CreatePrivateMessageReport endpoint had a bug that would allow anyone, not just the recipient, to create a report, and then receive the details about private messages.

This allowed anyone to iterate over ids, creating thousands of reports in order to receive details about private messages.

Since those reports are visible to admins, it would be easy to discover if someone was abusing this, and luckily we haven’t heard of anyone doing so on production instances (so far).

If you haven’t, please be sure to upgrade to at least 0.19.1 for the fix.

Many thanks to @Nothing4You for finding this one.

  • Dessalines@lemmy.mlOPMEnglish
    1·
    10 months ago

    Timing on publishing these is tricky. We let most server runners know about this ~a month ago now, and we’re now 2 versions past the bug.

    • Zagorath@aussie.zoneEnglish
      0·
      10 months ago

      As far as I’m aware the most widely-accepted standard for responsible disclosure is 90 days. This is a little different, since that’s normally between businesses and includes the time needed to develop a solution; it’s not typically aimed at federated or self-hosted applications rolling out an already-created patch. On the one hand, granting them that extra time to upgrade seems reasonable. On the other, wouldn’t anyone wanting to exploit a vulnerability be able to reverse-engineer it pretty easily by reading the git history?

      I dunno where I land on this, tbh.

      • example@reddthat.comEnglish
        1·
        10 months ago

        The 90 days disclosure you’re referencing, which I believe is primarily popularized by Google’s Project Zero process, is the time from when someone discovers and reports a vulnerability to the time it will be published by the reporter if there is no disclosure by the vendor by then.

        The disclosure by the vendor to their users (people running Lemmy instances in this case) is a completely separate topic, and, depending on the context, tends to happen quite differently from vendor to vendor.

        As an example, GitLab publishes security advisories the day the fixed version is released, e.g. https://about.gitlab.com/releases/2024/01/11/critical-security-release-gitlab-16-7-2-released/.
        Some vendors will choose to release a new version, wait a few weeks or so, then publish a security advisory about issues addressed in the previous release. One company I’ve frequently seen this with is Atlassian. This is also what happened with Lemmy in this case.

        As Lemmy is an open source project, anyone could go and review all commits for potential security impact and to determine whether something may be exploitable. This would similarly apply to any other open source project, regardless of whether the commit is pushed some time between releases or just before a release. If someone is determined enough and spends time on this they’ll be able to find vulnerabilities in various projects before an advisory is published.

        The “responsible” alternative for this would have been to publish an advisory at the time it was previously privately disclosed to admins of larger instances, which was right around the christmas holidays, when many people would already be preoccupied with other things in their life.