this post was submitted on 10 Jul 2023
240 points (100.0% liked)

Lemmy Administration

64 readers
2 users here now

Anything about running your own Lemmy instance. Including how to install it, maintain and customise it.

Be sure to check out the docs: https://join-lemmy.org/docs/en/administration/administration.html

If you have any problems, describe them here and we will try to help you fixing them.

founded 4 years ago
MODERATORS
 

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:

  1. Remove custom emoji
DELETE FROM custom_emoji_keyword;
DELETE FROM custom_emoji;
  1. 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();
  1. 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 (@sunaurus)

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:

https://github.com/LemmyNet/lemmy-ui/issues/1895

https://github.com/LemmyNet/lemmy-ui/pull/1897

you are viewing a single comment's thread
view the rest of the comments
[–] Dark_Arc 2 points 1 year ago (2 children)

Oof, okay well that's not how I would've done it. The JWT secret in the database itself could be a vulnerability (e.g., someone that gains read only access to the database could then use that as a wedge to create any JWT they wanted). I'm not sure if that's actually worth bringing up or not (it's a bit of an odd case).

[–] [email protected] 0 points 1 year ago* (last edited 1 year ago) (1 children)

afaik to generate those tokens, you configure a secret in an enviroment variable. You cannot generate tokens from looking at valid tokens within the database. Thus storing active tokens in the database is fine since you can always purge all active tokens as this post has also suggested.

[–] Dark_Arc 1 points 1 year ago* (last edited 1 year ago) (2 children)

This is the secret, not the tokens.

[–] [email protected] 1 points 1 year ago (1 children)

oh i see, they want to delete the secret instead of the active tokens. Yeah now i get what you mean. Seems kinda odd.

[–] Dark_Arc 2 points 1 year ago (1 children)

I don't know enough about Lemmy's JWT design, but some JWT designs don't store the JWT in a database at all, so the only correct response is to regenerate the secret and kill all the sessions by them failing the validity checks.

[–] [email protected] 0 points 1 year ago* (last edited 1 year ago) (1 children)
[–] Dark_Arc 1 points 1 year ago

No, you said you can't generate valid tokens within the database. I just told you this is the secret, not the tokens (that is present in the database).