Safely handling SVG via "Insert URL" (Discussion around CVE-2022-33994)

[rawrly]

What problem does this address?

There is a CVE that asserts a claim Gutenberg unsafely allows SVG files to be added to a page's content. The CVE in question is CVE-2022-33994 and is currently under review in NVD and poses no immediate risk to sites using Gutenberg to my knowledge.

I am creating this ticket to start a discussion, and gather ideas on what (if anything) Gutenberg can do to safely handle inserting SVGs via "insert URL" even for what appears to be unlikely scenarios.

Information about this CVE has already been shared publicly. I have reviewed it and believe there is low to no risk due to the requirement of theoretical scenarios to perform the attack. Therefor is safe to discuss and share ideas here for how we could defend against even a hypothetical attack.

Full write up vulnerability can be found here: https://blog.jitendrapatro.me/cve-2022-33994-stored-xss-in-wordpress/

A simple version can be summarized as:

• Gutenberg allows users to click "insert URL" and paste in a remote URL that points to an SVG file. Gutenberg then uses that value in the <img> tag when generating the HTML. SVG files may contain javascript, which makes them a security concern similar to XSS.

This is currently safe for the following reasons, both are protections which exist in the browser:

• Browsers do not run javascript found in SVGs added via an <img> tag
• The SVG file is hosted on another domain, modern browser's follow same-origin policies which will prevent the javascript fom accessing data in the application origin that is running Gutenberg.

This behavior is unsafe for the following reasons:

• Visitors to the site could right-click the image, open it, and the javascript within the SVG will be ran under a different origin fom the website where Gutenberg was ran. (See: same-origin policy) This is very similar risk to following a malicious link.
• A web application's same-origin policy could be insecure, if misconfigured CORS heads could allow any origin.
• An unknown vulnerability in a browser could be used to break existing browser protections explained above (this is a big hypothetical) allowing attacks even on pages loaded within the web application. (repeat: hypothetical)

What is your proposed solution?

With the information available it appears the CVE poses no immediate risk at this time. Existing browser level protections work as expected when testing, the solution may be to "do nothing".

My hope for this ticket is to share the risk and encourage discussion toward solutions (even if existing browser level protections are sufficient.).

[annezazu]

@ehti just seeing this and wanted to flag for you.

[webd-uk]

Wordfence is now sending out alerts regarding this issue.

[flexerd]

I am mentioned this at wordpress.org - Not only is WordFence sending out alerts to completely remove the plugin till a patch is available, they are labeling this as a "critical vulnerability" after scan.

This is the entry https://www.wordfence.com/threat-intel/vulnerabilities/wordpress-plugins/gutenberg/gutenberg-1373-authenticated-contributor-stored-cross-site-scripting

Whatever we may think about this vulnerability is it rather bad PR for Gutenberg - especially as there are thread that confuse core Gutenberg with the plugin. Is there anyone that can start a conversation with WordFence to get clarity as to what can be done to remove or temper this warning?

[PluginVulnerabilities]

If you look at the original source for this, they are claiming this is an issue with WordPress, not Gutenberg. Also, according to them, WordPress told this person it wasn't a vulnerability before they published their claim. What they are describing as a vulnerability can be done with both the classic editor and the block editor in WordPress itself. So if this was a vulnerability, it would need to be addressed in WordPress, not just the Gutenberg plugin.

Unfortunately, some irresponsible security providers, including Patchstack and Wordfence, are falsely claiming this is a vulnerability in Gutenberg. WordPress could and should warn that their data is unreliable, because this is hardly the only issue with their data. Earlier this year there was a widely exploited unfixed vulnerability that existed despite both of those providers claiming that it was fixed three months before, while also getting key details wrong.

The CEO of Wordfence recently responded to mention of their data quality issues by claiming their data is "impeccable", so there doesn't seem to be a willingness to admit they have a problem, much less an interest in avoiding mistakes like this in a systematic way. But in the fine print on their vulnerability listing linked to above, they mention an email address to contact them, if someone wants to let them know about this particular mistake.

[flexerd]

This is beginning to sounds a lot like the email SPAM labelling eco-system. The original post, comes across as someone finding a vulnerability where there really isn't one, or at least one that effects any CMS. That said is there someone specific that's able to formulate a proper technical response to this? IMO this is an important issue for the WordPress community.

[PluginVulnerabilities]

It doesn’t seem like a technical response is needed. WordPress already explained to the person behind the original claim that this wasn’t a vulnerability, but they ignored that. The person that created this issue is an employee of Patchstack and he seems to understand this isn’t really a vulnerability, but his company is claiming it is, anyway. If those in the security community want to make inaccurate claims, they can’t be stopped from doing that. WordPress can and should respond by warning about WordPress security providers doing that. As long as there isn’t a consequence for spreading misinformation, they are unlikely to stop.

[rawrly]

I'm just going to drop a few thoughts out there to help spur discussion toward solutions and/or options:

I'm not saying they're good solutions either, I'm just trying to spur the conversation (so please share your own solutions or ideas if you have some)

1. Filter remote URLs (somehow)

   This means anytime a remote SVG file is used in a block, either WordPress or the user's browser would pre-fetch the file and check if it appears malicious. Probably the most resource intensive idea.

2. Build a hook from the block editor that triggers to download remote SVG files to the web server. Then filter the local file.

   This bypasses one of the only controls (same-origin policies) that is working in our favor here.

3. Remove the "Insert URL.." button from Gutenberg.

   Key point here is removing the button, we could still allow image uploads (that WordPress can filter), just not remote images.

4. Do nothing.

   This is the current situation, however some security vendors are not communicating the risk inaccurately, leading to confusion and concerns from users as we are seeing in this ticket. (I attempted to discuss this with MITRE originally before I made this ticket. They refused to appeal the vulnerability)

5. Clarify the risk to end-users, work with any vendor claiming the vulnerability exists.

   This would be a lot easier if the vendors reporting the risk to the site owners made the risk more clear in their reports via lowering the severity score, or removing the CVE altogether.

If you agree that the communication around the CVE needs to be cleared up. Then you can also reach out to the organization that assigned the CVE (I believe it is MITRE for this case.) Companies like Patchstack, WordFence (etc..) are just aggregating MITRE's data, but if you pay for their service you can appeal to them too, ask them to clarify the risk in their reports and consider removing the CVE altogether.

[rawrly]

I politely reached out to MITRE regarding CVE-2022-33994 back in July 2022. They refused my appeal. (and that is what lead to this ticket being made.)

If anyone thinks they may have better luck than I did, please give it a try.

[flexerd]

I contact WordFence as a customer and urged them to at least properly explain the vulnerability consider removing it or at least looking carefully at what it claiming.

[flexerd]

@rawrly I looked into programmatically removing the Add From URL button from the image block as a temporary, and admittedly daft solution, but couldn't figure it out. This would be only for sites with a large number of Users or with Users outside the company.

[ehti]

Ideally we could get this appealed/rejected via MITRE - so far unsuccessful, so reaching out to the plugin companies (WF, Patchstack) if you're a paying customer would be good as @rawrly has mentioned.

[alextwordfence]

We (Wordfence) have removed this entry from our records. If you're using any of our software, you shouldn't be alerted about this anymore. Thanks @flexerd for bringing this to our attention!