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.ee
    link
    fedilink
    English
    arrow-up
    149
    arrow-down
    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.

    • cakeistheanswer@lemmy.fmhy.ml
      link
      fedilink
      English
      arrow-up
      25
      ·
      1 year ago

      More importantly the issue was tracked and resolved publicly.

      The issue of trust in corporate spaces gets used to bury these things, this is a good model on how to restore it in the open.

    • kryllic@programming.dev
      link
      fedilink
      English
      arrow-up
      2
      ·
      1 year ago

      I firmly believe open source is the future of software development and things like this really show off the strengths of this sort of collaborative work. Everyone benefits and it’s a great way to maintain high quality.

  • tiny_fingers@programming.dev
    link
    fedilink
    English
    arrow-up
    59
    ·
    1 year ago

    Security is crazy hard and having perfect security is impossible. Kudos to the dev team for resolving this so quickly.

    • peopleproblems@lemmy.world
      link
      fedilink
      English
      arrow-up
      13
      ·
      1 year ago

      It makes me think I should see about contributing. I’m not an expert in security flaws or pen testing, but having an extra set of eyes checking for vulnerabilities doesn’t hurt.

      Plus, in my experience, the vulnerabilities to watch out for are code that the developers didn’t write. Updating packages usually isn’t a problem until it’s discovered a major version update is necessary looks at Spring angrily

    • malloc@programming.dev
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 year ago

      In my opinion, the project would benefit from static vulnerability scanning. Low hanging fruit like this XSS would have definitely been flagged.

      Most of those providers even give it out for free for open source projects. So it wouldn’t hurt.

  • Marek Knápek@programming.dev
    link
    fedilink
    English
    arrow-up
    10
    arrow-down
    3
    ·
    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.dev
      link
      fedilink
      English
      arrow-up
      6
      ·
      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.

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

      Oh I forgot another line of defense / basic security mitigation. If a server produces an access token (such as JWT or any other old school cookie / session ID), pair it with an IP address. So in case of cookie theft, the attacker cannot use this cookie from his computer (IP address). If the IP changes (mobile / WiFi / ADSL / whatever), the legitimate user should log-in again, now storing two auth cookies. In case of another IP change, no problemo, one of the stored cookies will work. Of course limit validity of the cookie in time (lets, say, keep it valid only for a day or for a week or so).

      • eluvatar@programming.dev
        link
        fedilink
        English
        arrow-up
        6
        ·
        1 year ago

        I’m sorry you want a mobile user to login every time their IP address changes? Why bother to keep them authenticated at all, just make them login for every web request. /s

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

          It is trade-off between convenience and security. With my approach stolen cookies are not usable from different computer / IP, the attacker needs additional work, he needs the victim computer to do the harm, his computer cannot do any harm. The downside is the user needs another log-in in case of his external IP changes. How often is it? Switch between mobile/WiFi. Otherwise … almost never … maybe 1x per day? I’m not proposing to log-out the user after IP change, I’m proposing to keep multiple sessions (on server) / auth cookies (on client) for each IPv4 or IPv6 prefix (let’s say /56).

  • object_Object@programming.dev
    link
    fedilink
    English
    arrow-up
    2
    ·
    edit-2
    1 year ago

    If lenny-ui is already using a JSX based library (InfernoJS), why not use it? I can’t believe they construct HTML manually like that without a hint of escaping or stripping. Sure, many markdown renderers tell you to just slap it in __html or dangerouslySetInnerHtml but there are many that just parse the MD and let you render it with JSX!

    I also can’t believe there’s no CSP that stopped this. Sure, it’s a pain in the ass to configure with a nonce but this is literally the kind of thing it’s made to block!

      • Hexarei@programming.dev
        link
        fedilink
        arrow-up
        14
        ·
        1 year ago

        I realize that you’re using ‘my lord’ as a bit of an exclamation here, but I initially read it as you addressing the commenter as your lord. it just made me imagine you with a heavily British accent, going full medieval peasant style to mock the guy. I found that quite humorous.

    • sarsaparilyptus@lemmy.fmhy.ml
      link
      fedilink
      arrow-up
      33
      ·
      1 year ago

      This comment is so idiotic that its least stupid explanation is that it’s a false flag by a tankie to make their critics look like idiots.

    • jrgd@kbin.social
      link
      fedilink
      arrow-up
      28
      arrow-down
      1
      ·
      1 year ago

      Spreading FUD over a group of people’s intent with their software that they personally use is an odd take, when kbin could very well have similar vulnerabilities in its codebase. Federation is good as part of limiting the attack vector one of many implementations and a subset of all servers hosting and routing media content. Kbin is just another set of federated content servers, with there being no guarantee of who develops the software being inherently more competent than those who develop Lemmy.

    • tal@kbin.social
      link
      fedilink
      arrow-up
      25
      ·
      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.

      This is hardly a back door. The lemmy devs just screwed up.

      Use kbin instead.

      Kbin had a fix for an SQL injection exploit the other week. Both probably still have security holes that haven’t yet been identified.

      There are more eyes on the software as the userbase grows, and people are going to find more flaws. That’s just the way things go.

      • bioemerl@kbin.social
        link
        fedilink
        arrow-up
        1
        arrow-down
        19
        ·
        1 year ago

        This is hardly a back door.

        I literally said it wasn’t in my comment, it’s evidence of how easy it is to put one in down the line despite the fact this is open source software.

          • ImOnADiet@lemmygrad.ml
            link
            fedilink
            arrow-up
            11
            ·
            1 year ago

            yeah, kind of insane the grudge people hold about it, people like that user spread all these spooky posts about how the devs are communists coming to kill you or something and that’s why you should use kbin (I’m only slightly exaggerating, the way these people post about it makes it sound like the devs are directly involved with like human rights abuses or something lol)

      • bioemerl@kbin.social
        link
        fedilink
        arrow-up
        2
        arrow-down
        17
        ·
        1 year ago

        The Lemmy devs are ideological fans of communist China.

        They’re likely to cooperate with them down the line and take actions that compromise their software, send data to others who are in their circle, and so on and so forth.

        A lot of people say since Lemmy is open source you can trust it, but open source isn’t a protection against malicious code. Here you can see an example of just how easy it is to sneak something by. Even though this wasn’t a malicious example it still allowed admin accounts to be compromised

        • philm@programming.dev
          link
          fedilink
          arrow-up
          13
          ·
          edit-2
          1 year ago

          You seem to be coming up with conspiracy theories, don’t you?

          And you don’t seem to know how (developing) software works, and that people aren’t infallible when it comes to avoiding bugs.

          Popularity just also increases the attack surface to a project, all these bugs can absolutely also occur in kbin. Unless software is mathematically proven (which is practically impossible in this context), it’s always possible that there is a bug lurking around the corner.

          • bioemerl@kbin.social
            link
            fedilink
            arrow-up
            2
            arrow-down
            9
            ·
            1 year ago

            And you don’t seem to know how (developing) software works, and that people aren’t infallible when it comes to avoiding bugs.

            I’m literally a professional software developer.

            I’m also telling you that people are fallible, bugs are easily missed, and you shouldn’t trust a project to be secure just because it’s open source.

            Popularity just also increases the attack surface to a project, all these bugs can absolutely also occur in kbin.

            Yes.

            And kbin doesn’t have developers that have reason to attempt to create and support malicious code. You can trust them to at least attempt to keep the code base clean in good faith. You can’t trust Lemmy to do the same.

            • philm@programming.dev
              link
              fedilink
              arrow-up
              6
              ·
              edit-2
              1 year ago

              Why shouldn’t I trust Lemmy?

              I mean the devs are now finally able to finance themselves via donations, after years of work on a project I’ve always aspired to make (but don’t have the necessary drive and time for it). There are also a lot more developers now with lemmy.

              Just because you obviously don’t share their political view, doesn’t mean that they don’t want this thing to be censorship-resistant and impossible to take down (no matter whether it’s a left or right authoritarian state/entity). They are closer to anarchism and marxism, than they’re to Chinas (authoritarian) version of “communism” (as the right wing media likes to simplify this rather complex topic…).

              Everyone is more or less political, but it’s far fetched to allege the conspiracy that the devs are working together with the chinese government or something weird like that.

              • bioemerl@kbin.social
                link
                fedilink
                arrow-up
                1
                arrow-down
                8
                ·
                1 year ago

                Why shouldn’t I trust Lemmy?

                They are literally ideologically aligned with a state that runs the largest mass censorship program in the world.

                I mean the devs are now finally able to finance themselves via donations

                Doesn’t help. They’re still potentially malicious actors.

                Just because you obviously don’t share their political view,

                It’s just a sliiiight bit more extreme than a small difference.

                I also love how you’re jumping goal posts here after your other point totally failed to land.

                They are closer to anarchism and Marxism

                They literally regularly praise and support China through their moderation and consider negative talk about China western propaganda.

                • philm@programming.dev
                  link
                  fedilink
                  arrow-up
                  4
                  ·
                  1 year ago

                  It’s just a sliiiight bit more extreme than a small difference.

                  Like you’re on the other side of the spectrum (i.e. Nazi)?

                  Doesn’t help. They’re still potentially malicious actors.

                  Yeah in that sense everyone is a potential malicious actor, but it’s much less likely if all the code is publicly visible (open source), that this happens. Now especially as there are now a lot more people watching over the code and potentially future contributions (code review).

                  I trust these guys a lot more than most politicians or big companies (whether they’re obviously authoritarian like in china, russia or “democratic” like in the USA). Transparency is a much more important factor than ideology/political views IMHO (e.g. they could publicly claim that they’re rightwing, while they’re tankies and vice versa).

                  But to me all your comments feel like rootless conspiracy anyway…

        • NotNotMike@programming.dev
          link
          fedilink
          arrow-up
          2
          ·
          1 year ago

          I know you’re getting it from all angles right now, but

          Do you have a source for their support of Communist China? I know they’re purported communist, but I didn’t notice any outright support of the Chinese form of communism.

          Not trying to argue, but genuinely trying to stay informed

            • NotNotMike@programming.dev
              link
              fedilink
              arrow-up
              1
              ·
              1 year ago

              Thank you for the link. It’s interesting to see a lot of these points. It’s a massive undertaking, and is illuminating to see the other side of the coin, as it were.

              Too much to go through in one sitting but a lot to swallow

    • pjhenry1216@kbin.social
      link
      fedilink
      arrow-up
      20
      ·
      1 year ago

      This is a ridiculous take and fairly toxic. Don’t ruin any communities with unnecessary hate. It’s unwanted.

    • apis@kbin.social
      link
      fedilink
      arrow-up
      13
      arrow-down
      2
      ·
      edit-2
      1 year ago

      Tbf, there are far more pressing reasons for distrusting Tankies… Instances getting hacked is for sure aggravating, but it isn’t the gulag-backed paranoid ultra-corrupt authoritarian hellhole they so admire and wish to expand globally.

    • static@kbin.social
      link
      fedilink
      arrow-up
      8
      ·
      1 year ago

      This is just getting too big too fast.

      Lots of things change when you grow too fast, one of them is that any stupid failure will be found and exploited.
      The project will mature and get a better security process, that has nothing to do with politics.

    • ImOnADiet@lemmygrad.ml
      link
      fedilink
      arrow-up
      8
      ·
      1 year ago

      I’m sure kbin.social blocks lemmygrad, but in case it doesn’t: you are such a dork, please learn to not be a dork in the future. Thank you.

    • Bread@sh.itjust.works
      link
      fedilink
      arrow-up
      7
      ·
      1 year ago

      Its open source and a lot of people are looking at it. The odds it has a back door intentionally put there are slim to none. It would get noticed.

        • Bread@sh.itjust.works
          link
          fedilink
          arrow-up
          5
          ·
          1 year ago

          Don’t know, I don’t have enough information. Though my point were if it were intentional. I am going to hazard a guess by how they are scrambling to send out patches that it probably wasn’t intended by the creators.

          The kind of developers that would put a back door in their software probably are also working on things with far more value potential than an open source forum where they could easily be caught. Perhaps like banks or weapons depots.

          • bioemerl@kbin.social
            link
            fedilink
            arrow-up
            2
            arrow-down
            4
            ·
            1 year ago

            No. They didn’t catch this. It compromised an administrator on a massive instance.

            It wasn’t intentional. It proves that when it is intentional it’ll be easily done and it’s a mistake to trust the Lemmy code base.

            • Bread@sh.itjust.works
              link
              fedilink
              arrow-up
              3
              ·
              1 year ago

              And the problem was fixed right afterwards and is currently being pushed out for admins to update to. Look, like it or not, shit happens. Expecting it to be full proof is unrealistic. It is a young software.

              Just because it happened unintentionally, doesn’t prove that we can’t trust the developers to not put back doors in. Even if they did, why would they? What is there to gain for the developers adding a backdoor to it? Versus the risk of doing so? Is it ever worth the trouble when it is very much possible to find out if they did?

              Lemmy has no financial value. That is the point. We don’t use credit cards here, people rarely use their names, email verification isn’t mandatory on all instances, passwords are potentially useful but you still need to know who they belong to. It is just such a great risk to their reputation for such a small gain.

              • bioemerl@kbin.social
                link
                fedilink
                arrow-up
                1
                arrow-down
                3
                ·
                1 year ago

                And the problem was fixed right afterwards

                Which is expected. When it comes to security the fact it happened at all is the problem.

                I don’t expect the software to be fool proof. All software has bugs and problems, but this software is specifically developed by bad actors who will eventually use the platform to fuck you over.

                Just because it happened unintentionally, doesn’t prove that we can’t trust the developers

                The developers aren’t trustworthy on the account of their extremist ideology, not on account of this bug happening. This bug is evidence that despite the fact that this project is open source you should not just brush off that extremist ideal as “no big deal”.

                Lemmy has no financial value.

                And immense social value.

                • leviosa@programming.dev
                  link
                  fedilink
                  arrow-up
                  1
                  ·
                  edit-2
                  1 year ago

                  The developers aren’t trustworthy on the account of their extremist ideology…

                  What do you mean by that? Are they hell bent on using Rust Nightly and making overly-judicious use of .unwrap()?

                  edit: I see that you mean they are Marxist-adjacent.

                • Bread@sh.itjust.works
                  link
                  fedilink
                  arrow-up
                  1
                  ·
                  1 year ago

                  We can argue non stop about politics, but that isn’t the point. Whether or not we agree with their politics is irrelevant to their ability to build a social platform. Until we start to see their beliefs affecting their software decision making in a negative way, we cannot complain about it. As they may or may not have popular opinions, that is a very good reason for them to have a great platform. So they can share them without fear of retaliation.

                  However, they have so far done nothing to show they can’t be trusted to not make unbiased or malicious software. It is incredibly rude to assume they will.

                  If you have evidence showing they cannot be trusted, please come forth with it. We need to know it.

    • gravitas_deficiency@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      9
      arrow-down
      2
      ·
      1 year ago

      Lmao you very clearly have absolutely no idea what you’re talking about.

      I dislike tankies myself, but this was absolutely not a backdoor.

      • bioemerl@kbin.social
        link
        fedilink
        arrow-up
        1
        arrow-down
        12
        ·
        1 year ago

        I literally said this wasn’t in my comment. This is evidence of how easy it is to sneak in a back door.

          • bioemerl@kbin.social
            link
            fedilink
            arrow-up
            1
            arrow-down
            7
            ·
            1 year ago

            And you’re aggressively confidently wrong. Evidence by the fact that you give literally zero reasoning.

            The fact a bug like this can happen is clear and obvious evidence for how these things can happen, and this was just stupidity, not targeted malice.

            • gravitas_deficiency@sh.itjust.works
              link
              fedilink
              English
              arrow-up
              6
              ·
              1 year ago

              Lmao go touch grass my guy.

              It’s not a backdoor. It wasn’t malicious. Yes, some major contributors are tankies, but that doesn’t really matter. That’s the beauty of OSS: everyone can see the code, which means everyone can spot sketchy shit - either malicious or completely accidental - and fix it. The fact that a patch was published in a matter of literally hours is confirmation of this.

              If this was a malicious exploit, it’d have been obscured far more, it would likely encompass more than a handful of insecure data-handling statements, and we’d have seen a LOT more instances getting popped.

              • bioemerl@kbin.social
                link
                fedilink
                arrow-up
                2
                arrow-down
                5
                ·
                edit-2
                1 year ago

                It’s not a backdoor. It wasn’t malicious

                Read my comment again. I literally said this wasn’t. I said this is experience that it could be easily done in the future.

                everyone can see the code, which means everyone can spot sketchy shit - either malicious or completely accidental - and fix it.

                Didn’t help in this case. Open Source doesn’t fix malicious contributions, and when the project owners are the malicious source your have no safeguards. Trust is still essential.

                If this was a malicious exploit, it’d have been obscured far more,

                Ex-fucking-xactly

                • gravitas_deficiency@sh.itjust.works
                  link
                  fedilink
                  English
                  arrow-up
                  2
                  ·
                  1 year ago

                  I’m not going to litigate the entire topic of trust within the context of software and systems engineering with you.

                  This is the sort of Reddit interaction that I don’t miss.