UPDATE: The latest RC version of Lemmy-ui (0.18.2-rc.2) contains fixes for the issue, but if you believe you were vulnerable, you should still rotate your JWT secret after upgrading! Read below for instructions. Removing custom emoji is no longer necessary after upgrading.
Original post follows:
This post is intended as a central place that admins can reference regarding the XSS incident from this morning.
What happened?
A couple of the bigger Lemmy instances had several user accounts compromised through stolen authentication cookies. Some of these cookies belonged to admins, these admin cookies were used to deface instances. Only users that opened pages with malicious content during the incident were vulnerable. The malicious content was possible due to a bug with rendering custom emojis.
Stolen cookies gave attackers access to all private messages and e-mail addresses of affected users.
Am I vulnerable?
If your instance has ANY custom emojis, you are vulnerable. Note that it appears only local custom emojis are affected, so federated content with custom emojis from other instances should be safe.
I had custom emojis on my instance, what should I do?
This should be enough to mitigate now:
- Remove custom emoji
DELETE FROM custom_emoji_keyword;
DELETE FROM custom_emoji;
- Rotate your JWT secret (invalidates all current login sessions)
-- back up your secret first, just in case
SELECT * FROM secret;
-- generate a new secret
UPDATE secret SET jwt_secret = gen_random_uuid();
- Restart Lemmy server
If you need help with any of this, you can reach out to me on Matrix (@sunaurus:matrix.org) or on Discord ()
Legal
If your instance was affected, you may have some legal obligations. Please check this comment for more info: https://lemmy.world/comment/1064402
More context:
Thanks for posting. There really should be a button which allows the admins to log everyone out for crisis situations like there I think
Changing the JWT secret does this. So instead of a button, its a line of code, making it less likely to be done by mistake.
True as that is, not every admin has DB access and those with DB access might be AFK.
Surely this exploit proves that it’s best to minimise the number of administrative actions available in the UI?
In crisis situations like this, the last thing you want is to rely on some portion of the application UI working.
If the UI doesn’t work, there’s always the DB directly. But it’s good to have that option.
JWT secret keys are not in the DB (speaking typically, maybe for Lemmy they are, but that would be very surprising), that’s typically an environment variable or configuration file sort of thing.
In any case, this isn’t the part that’s broken, it doesn’t need fixed.
