Possible XSS attack - Githubissues

NomNuggetNom commented 1 year ago

Requirements

[X] This is a bug report, and if not, please post to https://lemmy.ml/c/lemmy_support instead.
[X] Please check to see if this issue already exists.
[X] It's a single bug. Do not report multiple bugs in one issue.
[X] It's a frontend issue, not a backend issue; Otherwise please create an issue on the backend repo instead.

Summary

The sidebar dangerously sets HTML but does not configure the Markdown render to strip HTML codes. This enables simple XSS attacks like <img onload="maliciousCodeHere()" />. It seems like an attempt is made to create a markdown renderer with HTML disabled, however.

It now seems that this attack might be done via custom emojis.

Steps to Reproduce

Technical Details

markdown-it does some extremely simple guarding, but they don't claim to prevent XSS. Custom HTML should be removed in favor of plugins.

Lemmy Instance Version

0.18.1

Lemmy Instance URL

No response

rcmaehl commented 1 year ago

@sunaurus I think it would be good to learn from this and add some automated method to quickly deploy urgent security patches. There are thousands of lemmy instances and it will take forever for all of them to update.

I'm not suggesting fully automated software updates, just some way to quickly patch a critical vulnerability like this one.

Maybe with an opt-in/opt-out option because I'm sure some very specific admins will be up in arms about the potential abuse.

ornato-t commented 1 year ago

Hey everyone, admin of forum.basedcount.com here. Sorry in advance for the trouble that this is giving to you. I'll go ahead and update my instance to the latest rc, as well as follow all the tips in this issue.

EDIT: in the meantime I've shut down the instance. I'm trying my hardest to stop this from proliferaring, at least through our instance.

finnim commented 1 year ago

Maybe with an opt-in/opt-out option because I'm sure some very specific admins will be up in arms about the potential abuse.

I would definitely welcome an API endpoint controlled by a few trusted instance admins that could be polled every minute or so with a very simple GET request.

In the case of a security issue that requires immediate attention by an admin or sysadmin I would have my server shutdown or stop all containers if it receives a certain agreed-upon response.

This is the only way we can have small instances run by few people who might be asleep without them becoming attack vectors.

Worst case it's a false positive and my instance goes down, but I rather have this than compromise any user data.

Thinking about it, this could also be a useful warning service for a multitude of scenarios. I'll consider setting up a button for authenticated users to press, in this case not to shut down the instance but to give me some sort of alert for medium-tier incidents.

SexyVetra commented 1 year ago

an API endpoint controlled by a few trusted instance admins

I think you meant to propose checking for GitHub for new releases instead of adding a new points of failure and additional vulnerability surfaces

grahhnt commented 1 year ago

For future reference, this was patched by commit e80bcf53acb8ce25ed5ef6b7eb16b90f0b07e8f1 and became available in version v0.18.2-rc.1

abhibeckert commented 1 year ago

@sunaurus I think it would be good to learn from this and add some automated method to quickly deploy urgent security patches. There are thousands of lemmy instances and it will take forever for all of them to update. I'm not suggesting fully automated software updates, just some way to quickly patch a critical vulnerability like this one.

Maybe with an opt-in/opt-out option because I'm sure some very specific admins will be up in arms about the potential abuse.

Sure... that option needs to exist, but it maybe don't make it too easy?

Automatically applying security patches is standard practice and the potential for abuse by a rogue Lemmy developer is vastly smaller than the potential abuse from a delayed installation.

If I was running a Lemmy instance, I would be defederating every instance that hasn't updated to v0.18.2.rc.1 until they do update. If instance admins want to, you know, sleep, then these patches need to be automated.

kevincox commented 1 year ago

What would defederation accomplish? The patch is in the client, patched servers can still send messages that trigger the bug. The problem is that the UI renders it insecurely.

Let's not get too excited. I think that there should be a designated channel for vulnerability announcements but I don't think we need to jump straight to automatically installing new code on servers. Without very careful design that can add worse vulnerabilities than it would prevent.

abhibeckert commented 1 year ago

What would defederation accomplish?

It would force those instance admins to update.

Also.. Admin and moderator accounts have been accessed on some of those servers. Login tokens for any (all?) other users may have also been compromised. And they have been posting links to illegal content.

The patch doesn't reset those JWT tokens either. So while the barn door is closed once instances update the wolf could be locked inside with the chickens.

fkrauthan commented 1 year ago

Also why should anyone install an RC version? Please release an official patch version. No one should have to install an RC to patch a bug.

SineSwiper commented 1 year ago

For future reference, this was patched by commit e80bcf5 and became available in version v0.18.2-rc.1

This is a serious enough issue to backport this to an official version.

dessalines commented 1 year ago

We plan on doing a release with a fix tomorrow, please be patient.

geneccx commented 1 year ago