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.
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.
This is what happens when the people running a platform actually care about it and it’s users
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.
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.
Security is crazy hard and having perfect security is impossible. Kudos to the dev team for resolving this so quickly.
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
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.
Looks like they posted some more updates scene I check this morning:
- Recap of the Lemmy XSS incident & steps for mitigation
- Lemmy.world (and some others) were hacked
u/spez did it!
Paid someone to do it, that man can’t code.
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.
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.
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
HttpOnlyheader, 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.
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).
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
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).
This would never happen in desktop/server application
MOVEit would suggest otherwise.
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!
I feel like we’ve had enough posts about this now?
I’m not sure you understand how sorting works. This was probably posted in multiple comms in multiple instances.
Removed by mod
This is the dumbest possible take about the situation, my lord.
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.
Something something landed gentry
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.
Jesus, how deep does this conspiracy go!
Ooohhhhh… it’s IN the computer…
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.
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.
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.
You must not understand how open source works
Well he absolutely must learn how open source works.
But he doesn’t understand how it works.
(Sorry for the correction…)
This is a ridiculous take and fairly toxic. Don’t ruin any communities with unnecessary hate. It’s unwanted.
And this is why you don’t trust tankies
What are you referring to here?
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
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.
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.
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.
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.
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…
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
I think to get the best view of their political stance is to read dessalines essays.
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
Check out lemmy.ml, which is the devs instance. You’ll see it very quickly.
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.
One is a step to the other.
McCarthy, is that you?
Lmao you very clearly have absolutely no idea what you’re talking about.
I dislike tankies myself, but this was absolutely not a backdoor.
I literally said this wasn’t in my comment. This is evidence of how easy it is to sneak in a back door.
This comment further underlines to me that you have absolutely no idea what the fuck you’re talking about.
You’re out of your element, Donny.
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.
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.
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
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.
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.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.
Did they catch this?
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.
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.
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.
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.
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.
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.
deleted by creator
