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\")
Have you tried sending the API request for the sidebar edit yourself? Maybe the escaping is only done at the UI level (which would be EXTREMELY bad).
EDIT: no, couldn’t find anything via comments
I’ve even checked in the database directly - the markdown exploit is pasted exactly as is from the JSON I shared here (passed through jq to strip the JSON-encoding), with the only difference being I replaced lemonparty with example.com.
It renders, I get the image, but it’s escaped properly. Both the affected instances so far are running some RC / version number shows a git commit, so maybe there’s something weird about the build config that results in slightly different parsing.
I’ve very puzzled about it. I tried it in sidebar, I tried it as taglines (where lemmy.world’s exploit was), I tried it as a post, I tried it as a comment. All of them result in the same correct output. I’ve even added the trailing space at the end in case it matters.
I’m open if you have more ideas.
E: database:
see my edit on the comment you just responded to, I just injected an “alert”
On which instance? It renders fine on mine: https://lemmy.max-p.me/comment/101376
Seems to render fine there as well: https://sh.itjust.works/comment/862442
And there as well: https://lemmy.ml/comment/1406331
In all cases:
I’ve even tried Chromium just in case Firefox was auto-fixing it.
I’m confused now, does it really work on your end?
I’m wrong sorry, Firefox’s inspector deceived me but when you look at the HTML it’s indeed escaped, I definitely need to go to sleep
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.