Lemmy.world and other instances hacked - Lemmy.world
lemmy.world
A number of Lemmy instances have been hacked overnight. Some may remain inaccessible until they have been secured and restarted. As a safety precaution logged-on sessions on many servers have been cancelled and you are required to logon again. Unfortunately, the only way I could find to do this in Liftoff! is by going to Settings > Accounts and deleting each local account by long pressing on it, and then create it again. All your posts, comments and bookmarks should be preserved during this process. Please see the linked posts for further details as they emerge. Thanks all, and please bear with us as this gets resolved.

Drawing attention on this instance so Admins are aware and can address the propagating exploit.

EDIT: Found more info about the patch.

A more thorough recap of the issue.

GitHub PR fixing the bug: https://github.com/LemmyNet/lemmy-ui/pull/1897/files

If your instance has custom emojis defined, this is exploitable everywhere Markdown is available. It is NOT restricted to admins, but can be used to steal an admin’s JWT, which then lets the attacker get into that admin’s account which can then spread the exploit further by putting it somewhere where it’s rendered on every single page and then deface the site.

If your instance doesn’t have any custom emojis, you are safe, the exploit requires custom emojis to trigger the bad code branch.

  • FBelaza@lemm.eeEnglish
    1·
    1 year ago

    I’m greatly surprised how Lemmy and the fediverse society has responded with this. The bug was found yesterday, maybe? And I’ve read about it three, four times (in different servers); a temporal solution was published in hours and it’s already patched on the repo.

    Another victory for Open Source and the Fediverse in general.

  • bioemerl@kbin.social
    0·
    1 year ago

    And this is why you don’t trust tankies. It’s very easy to compromise the software and put back doors into it.

    Use kbin instead.

    And this is not me saying that this is a case of that, this is me saying that this could be the case in the future

  • Marek Knápek@programming.devEnglish
    0·
    1 year ago

    So what happened:

    • Someone posted a post.
    • The post contained some instruction to display custom emoji.
    • So far so good.
    • There is a bug in JavaScript (TypeScript) that runs on client’s machine (arbitrary code execution?).
    • The attacker leveraged the bug to grab victim’s JWT (cookie) when the victim visited the page with that post.
    • The attacker used the grabbed JWTs to log-in as victim (some of them were admins) and do bad stuff on the server.

    Am I right?

    I’m old-school developer/programmer and it seems that web is peace of sheet. Basic security stuff violated:

    • User provided content (post using custom emojis) caused havoc when processing (doesn’t matter if on server or on client). This is lack of sanitization of user-provided-data.
    • JavaScript (TypeScript) has access to cookies (and thus JWT). This should be handled by web browser, not JS. In case of log-in, in HTTPS POST request and in case of response of successful log-in, in HTTPS POST response. Then, in case of requesting web page, again, it should be handled in HTTPS GET request. This is lack of using least permissions as possible, JS should not have access to cookies.
    • How the attacker got those JWTs? JavaScript sent them to him? Web browser sent them to him when requesting resources form his server? This is lack of site isolation, one web page should not have access to other domains, requesting data form them or sending data to them.
    • The attacker logged-in as admin and caused havoc. Again, this should not be possible, admins should have normal level of access to the site, exactly the same as normal users do. Then, if they want to administer something, they should log-in using separate username + password into separate log-in form and display completely different web page, not allowing them to do the actions normal users can do. You know, separate UI/applications for users and for admins.

    Am I right? Correct me if I’m wrong.

    Again, web is peace of sheet. This would never happen in desktop/server application. Any of the bullet points above would prevent this from happening. Even if the previous bullet point failed to do its job. Am I too naïve? Maybe.

    Marek.

    • Ethan@programming.devEnglish
      1·
      1 year ago

      User provided content (post using custom emojis) caused havoc when processing (doesn’t matter if on server or on client). This is lack of sanitization of user-provided-data.

      100%. Always act as though user provided content is malicious.

      JavaScript (TypeScript) has access to cookies (and thus JWT). This should be handled by web browser, not JS.

      Uh… what? JavaScript is a client-side language (unless you’re using NodeJS, which Lemmy is not). Which means JavaScript runs in the browser. And that JavaScript has access to cookies, that’s just a basic part of how web browsers work. Lemmy can’t do anything to prevent that.

      How the attacker got those JWTs? JavaScript sent them to him? Web browser sent them to him when requesting resources form his server? This is lack of site isolation, one web page should not have access to other domains, requesting data form them or sending data to them.

      Again, Lemmy can’t do anything about that. Once there’s a vulnerability that allows an attacker to inject arbitrary JS into the site, Lemmy can’t do anything to prevent that JS from making requests.

      Then, if they want to administer something, they should log-in using separate username + password into separate log-in form and display completely different web page

      On the backend you’d still have a single system which kind of defeats the purpose. Unless you’re proposing a completely independent backend? Because that would be a massive PITA to build and would drastically increase the system’s complexity and reduce maintainability.