419
submitted 11 months ago* (last edited 11 months ago) by varsock to c/meta

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.

top 50 comments
sorted by: hot top controversial new old
[-] [email protected] 147 points 11 months 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.

[-] [email protected] 26 points 11 months ago

This is what happens when the people running a platform actually care about it and it's users

[-] [email protected] 25 points 11 months 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.

load more comments (1 replies)
[-] tiny_fingers 59 points 11 months ago

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

[-] [email protected] 13 points 11 months 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

load more comments (1 replies)
[-] ruffsl 18 points 11 months ago

Looks like they posted some more updates scene I check this morning:

[-] askat 17 points 11 months ago
[-] [email protected] 11 points 11 months ago

Paid someone to do it, that man can't code.

[-] MarekKnapek 7 points 11 months 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.

[-] firelizzard 5 points 11 months 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.

[-] MarekKnapek 3 points 11 months 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.

[-] MarekKnapek 5 points 11 months 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 6 points 11 months 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

load more comments (1 replies)
[-] Hector_McG 4 points 11 months ago

This would never happen in desktop/server application

MOVEit would suggest otherwise.

[-] object_Object 2 points 11 months ago* (last edited 11 months 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!

load more comments
view more: next ›
this post was submitted on 10 Jul 2023
419 points (98.6% liked)

Programming.dev Meta

2375 readers
33 users here now

Welcome to the Programming.dev meta community!

This is a community for discussing things about programming.dev itself.

Links

Credits

founded 1 year ago
MODERATORS