DO NOT OPEN THE “LEGAL” PAGE
lemmy.world is a victim of an XSS attack right now and the hacker simply injected a JavaScript redirection into the sidebar.
It appears the Lemmy backend does not escape HTML in the main sidebar. Not sure if this is also true for community sidebars.
EDIT:
the exploit is also in the tagline that appears on top of the main feed for status updates, like the following one for SDF Chatter:
EDIT 2:
The legal information field also has that exploit, so that when you go to the “Legal” page it shows the HTML unescaped, but fortunately (for now) he’s using double-quotes.
"legal_information":" ![\" onload=\"if(localStorage.getItem(`h`) != `true`){document.body.innerHTML = `\u003Ch1\u003ESite has been seized by Reddit for copyright infringment\u003C\u002Fh1\u003E`; setTimeout(() =\u003E {window.location.href = `https:\u002F\u002Flemmy.world\u002Fpictrs\u002Fimage\u002F7aa772b7-9416-45d1-805b-36ec21be9f66.mp4`}, 10000)}\"](https:\u002F\u002Flemmy.world\u002Fpictrs\u002Fimage\u002F66ca36df-4ada-47b3-9169-01870d8fb0ac.png \"lw\")
See the edit on the original thread, it’s apparently the tagline (where a message can be shown above the main feed).
I tried taglines.
Looks like the key was custom emojis: https://github.com/LemmyNet/lemmy-ui/pull/1897/files
That probably explains the
"lm"bit after, makes the parser do something which results in the code not being properly escaped and boom.I’m guessing now that the exploit has to be tweaked for individual instances to trigger this, to target an emoji the instance has which makes the check go into that branch. I don’t have any on mine so I couldn’t possibly trigger the bug.
I’ll try to play with that and see if I can trigger it with that extra knowledge.
You’re right but then that means only a compromised admin account can do that (and that is the case on lemmy.world with Michelle’s account). The thing is it happened on other instances too, so I’m very inclined to think that there’s also something going on with comments or community sidebars.
Voilà!
It’s a Markdown bug and it does work everywhere, but it’s only exploitable when it matches a custom emoji defined by the instance. It only works on the instance where the emoji is defined for some reason, as it causes the check to fail. As soon as I deleted the emoji, it stopped working without changing the test post at all. I’ve left the emoji deleted because then I’m open to getting my account exploited.
So, it’s exploitable by anyone on the instance as long as the instance has custom emojis. But then if you can trick an admin to visit a page with the exploit code, you can use that to extract the user’s JWT and send it elsewhere, from which then you breach the admin account and can further put the exploit in taglines/sidebars and whatnot. And because of the JWT bugs, even disabling the account doesn’t work because the JWT doesn’t get invalidated.
Don’t you find it weird that the “fix” that is being proposed is only changing the UI? In a sense, we’re still trusting the front-end while unescaped HTML is still being stored in the database.
It’s converted from Markdown to HTML in the frontend, it’s not stored as HTML in the database.
Editing posts would be a trainwreck otherwise.