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.

  • Ethan@programming.dev
    link
    fedilink
    English
    arrow-up
    5
    ·
    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.

    • Marek Knápek@programming.dev
      link
      fedilink
      English
      arrow-up
      4
      arrow-down
      1
      ·
      1 year ago

      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.

      Yes and No. Cookies could be accessed by JS on the client. BUT. When the cookie is sent by the server with additional HttpOnly header, then the cookie cannot be accessed from JS. Look at Lemmy GitHub issue, they discuss exactly this. Lemmy server absolutely has power to prevent this.

      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.

      I believe they can. But I’m not sure about this one. The server could send a response preventing the web browser to request content from other domains. Banks are using this. There was an attack years ago when attacker created a web page with i-frame in it. The i-frame was full screen to confuse the victim it is actually using the Banks site and not the attacker site. The bank web site was inside the inner i-frame, the code in the outer frame then had access to sensitive data in the inner frame. I believe there are HTTP response headers that instruct the web browser to not allow this. But I’m not sure I remember how exactly this works.

      completely independent backend

      Yes, it would be more costly, but more secure. It is trade-off, which one is more important to you? In case of chat/blog/forum app such as Lemmy I prefer cheap, in case of my Bank website I prefer secure.