Rocket.chat: SVG with several XLink references makes browser unresponsive

[99991]

Description:

Posting this link makes the chat unresponsive:

https://happy-stallman-6c63b7.netlify.com/bug.svg

Steps to reproduce:

1. Post this link: https://happy-stallman-6c63b7.netlify.com/bug.svg

Expected behavior:

The chat should not become unresponsive.

Actual behavior:

The chat becomes unresponsive.

Server Setup Information:

Every possible setup.

Additional context

No additional context required.

Relevant logs:

No relevant logs.

[knrt10]

@99991 would you please specify this issue with the issue template, otherwise, this will be closed. Thanks 👍

[99991]

No problem! I deleted the part where I suggest a possible fix because there was no applicable point in the template.

[fliptrail]

Why can't I load the svg normally?

[99991]

It takes a few hours to load.

[tassoevan]

Welp, I don't see any workaround for arbitrary SVG rendering other than disabling any SVG image preview.

[99991]

Here are a few solutions:

• Try to convert the SVG to PNG and if that takes longer than some arbitrary duration, don't embed the image: timeout 1s convert bug.svg test.png; echo $? (Could use some SVG rendering library in a separate process instead of convert tool) - The easiest solution, but makes server vulnerable to denial-of-service if SVG uploads are not limited.
• Parse the SVG and calculate number of nodes. Don't embed SVGs with more than some number of nodes. - The most elegant solution, but requires more work.
• Keep bugging browser vendors until they fix this denial-of-service vector. - Probably futile. At least the Chrome devs think that "crashing is a reasonable thing to do". (link is to issue for XML billion laughs attack, but issues with SVG got merged into this issue) The issue in the firefox bugtracker is still open after 11 years.

[tassoevan]

@99991 Thanks, I was struggling to remember the attack name.