[BUG] CVE claim: An arbitrary file upload vulnerability in the file upload module of Tiddlywiki5 v5.2.2 allows attackers to execute arbitrary code via a crafted SVG file.

[CrossEye]

Describe the bug

I don't know if this was a real bug in 5.2.2 or some nonsense from Mitre. But they are reporting CVE-2022-29351. This is showing up as a critical vulnerability in whatever tool GigantiCorp, where I work, uses for vulnerability tracking, even though it's installing 5.2.5. And don't ask: I have no idea why it's not trying for 5.2.7 -- maybe something to do with bug and maybe not.

I've been using some forgiveness-not-permission magic to write a largish documentation wiki in TW; no one's been screaming at me yet. But I'm afraid to announce this too widely for fear someone will look at this supposedly critical vulnerability and tell me I have to stop.

AFAICT, this does not affect 5.2.5, I don't know if it actually affected 5.2.2, where it was reported.

I've had some pretty terrible experiences with these security companies. My first dust-up with them is documented in a StackOverflow Q&A. Very briefly, someone raised an issue on a project I maintain, claiming we had a security issue. I responded to explain how that wasn't true, kept the issue open for discussion, only to find that Veracode had picked that up as a true report, and I spent weeks trying to demonstrate that no, my library didn't have the vulnerability. It was an extremely frustrating experience, but was eventually resolved, and they wrote a blog post describing the supposed vulnerability and how my library in fact did not exhibit it. A frustrating experience, but a satisfying conclusion.

Six months later another company, Mitre, started the same thing. I can get no satisfaction from them, and it's driven me from any interest in trying to maintain that library.

Here, I'm just wondering if this was ever a bug, if it is now, and if anyone is trying to resolve this with Mitre.

To Reproduce

I cannot confirm this myself, but the report says to

1. Drag svgavatar.svg to a tiddlywiki
2. See that this generates an alert, demoing untrusted code execution

[Jermolene]

Hi @CrossEye - CVE-2022-29351 is nonsense.

I received an email from a graduate student at Florida International University in April 2022 saying that they had found a vulnerability in TW5 related to "Unrestricted File Uploads". I responded asking for more details and they sent through the material that you'll now see listed on the CVE database. At that point I ignored them because it seemed like it wasn't a good faith report.

A month or so later I received an email from a member of the Snyk Security Team saying "I am unfamiliar with this project and how it is being used, I was interested to know whether there are actual security implications to this issue? Before adding this CVE into our DB I wonder if it would be possible to get your confirmation regarding this matter if this is a vulnerability or not". I responded:

As far as I can tell, they have scanned GitHub for projects that support uploading files on the basis that they are vulnerable to uploading a malicious SVG.

They didn't show any analysis of the practical impact of the vulnerability. TiddlyWiki is documented as a personal wiki. The threat model of the basic project does not extend to worrying about malicious actors who have legitimate write access to the system.

The Snyk representative responded:

The reason I would like to verify that with you, is that we found [...name...] released many CVEs while some of them are not considered as vulnerabilities.

At that point I assumed that the "vulnerability" wouldn't be added to the CVE database, and so I didn't pay any further attention.

If it is on the public CVE database then it probably is worth us trying to get it amended somehow, but I've no prior experience of this kind of thing, and don't know how to proceed.

[CrossEye]

I've had no success fighting with Mitre, but my enthusiasm for doing so was definitely drained by my prior experience with Veracode. On that bug page, they have a link to https://cveform.mitre.org/, where you're supposed to be able to request an update to a CVE. I did that, then emailed them several times when I got no changes, and basically gave up in disgust, and have only interacted with the FOSS world since with TW, and then mostly as a knowledge-seeking user.

At some point I will get back to it, and try to fight Mitre again. I don't know how serious this would be in general, but it might prevent official adoption at my huge conservative financial services company. There are probably others in similar circumstances.

Overall, snyck looks like the best ones to deal with. I had a similar experience with them, and sent them my analysis of why it was not a problem, got back a thank-you note, and that was the end of it.

[pmario]

I cannot confirm this myself, but the report says to

You can not confirm it, since nothing happens. ...

If the SVG snippet is copy - pasted to a tiddler and the HTML renderer sees the SCRIPT tag it will be converted to SAFE-SCRIPT which in turn will NOT be executed by the browser since it't not a SCRIPT tag anymore.

If you copy paste this into a tiddler -- nothing will happen

<svg version="1.1" baseProfile="full" xmlns="http://www.w3.org/2000/svg">
   <polygon id="triangle" points="0,0 0,50 50,0" fill="#009900" stroke="#004400"/>
   <script type="text/javascript">
      alert(document.domain);
   </script>
</svg>

because the HTML output is

<p><svg baseProfile="full" version="1.1" xmlns="http://www.w3.org/2000/svg">
   <polygon fill="#009900" id="triangle" points="0,0 0,50 50,0" stroke="#004400"></polygon>
   <safe-script type="text/javascript">
      alert(document.domain);
   </safe-script>
</svg></p>

[Jermolene]

I've had no success fighting with Mitre, but my enthusiasm for doing so was definitely drained by my prior experience with Veracode. On that bug page, they have a link to https://cveform.mitre.org/, where you're supposed to be able to request an update to a CVE. I did that, then emailed them several times when I got no changes, and basically gave up in disgust, and have only interacted with the FOSS world since with TW, and then mostly as a knowledge-seeking user.

At some point I will get back to it, and try to fight Mitre again. I don't know how serious this would be in general, but it might prevent official adoption at my huge conservative financial services company. There are probably others in similar circumstances.

Good to know @CrossEye. I agree that this might well be an issue for some users, and I would like to address it if we can.

Overall, snyck looks like the best ones to deal with. I had a similar experience with them, and sent them my analysis of why it was not a problem, got back a thank-you note, and that was the end of it.

You can not confirm it, since nothing happens. ...

@pmario - indeed, the "vulnerability" doesn't occur when the SVG tiddler has a wikitext content type, but it does occur when the SVG tiddler has the type image/svg+xml.

[CrossEye]

I cannot confirm this myself, but the report says to

You can not confirm it, since nothing happens. ...

I know that for the 5.2.3 - 5.2.7 I happened to have around and tested. I didn't try to dig out a 5.2.2, the version on which it was reported, That's all I meant. But I suspect it's never been an issue, and this was just someone indiscriminately spraying around bug reports. Such people are simply menaces.

[CrossEye]

I'm not a particularly visual person, so I hadn't looked at the video included with this issue. I just checked now. And the whole point is that they embed the script:

   <script type="text/javascript">
      alert(document.domain);
   </script>

into the uploaded SVG. Well they demo the script firing by uploading/embedding the image, and then opening the image in a new tab. At this point the script fires, but the alert is empty. It doesn't have access to document.domain!

This is definitely nonsense. If no one else has done so, I can fill out Mitre's form to challenge this. But I haven't had much luck getting them to respond.

[pmario]

@pmario - indeed, the "vulnerability" doesn't occur when the SVG tiddler has a wikitext content type, but it does occur when the SVG tiddler has the type image/svg+xml.

With FF and Edge on windows I do not get an alert with type: image/svg+xml

[pmario]

OK. ... The video says we have to right-click and open the image in a new tab. ... hmmm. So the import process would have to sanitize <script> tags, instead of the rendering process.

[CrossEye]

But that doesn't matter from our perspective. Opening in a new tab has already lost access to the document.

My guess is that on some sites with other upload processes, such a script will execute in the context of the page, and then will spill your milk, steal your girlfriend, and launch the missiles. It seems unimportant here.

Please let me know if I should update the Mitre page and see if anything happens. It might be better coming from a core committer, but I'm willing to do it if no one else wants to.

[pmario]

.. But that doesn't matter from our perspective. Opening in a new tab has already lost access to the document.

You are right. ... I do not know, if such a behaviour is considered a security risk.

Just thinking ... It may be possible to use some code to forward the user to evilsite-com and steal some info from there.

May be @Jermolene can use his contact at Snyk and ask them if this is considered a vulnerability.

[Jermolene]

The funny thing is that I don't think that this issue behaves any differently than making an HTML tiddler consisting of an HTML file with a <script> tag....

[CrossEye]

Perhaps not, but people probably do have different expectations of the behavior when uploading HTML or JS files than when uploading images. The point of this is clear enough: even allowing the uploading of images might not be safe. But there don't seem to be any concerns for TW.

[matthewweippert]

Unfortunately, this issue also shows up in NIST's National Vulnerability Database as CVE-2022-29351. The description claims:

An arbitrary file upload vulnerability in the file upload module of Tiddlywiki5 v5.2.2 allows attackers to execute arbitrary code via a crafted SVG file.

I think many people, corporations, and government agencies might be unwilling or unable to use TiddlyWiki until that CVE is somehow resolved. It sounds like that claim is bogus, but we're probably in a guilty until proven innocent scenario.

For clarification, it sounds like TiddlyWiki is not adding any vulnerability over what any web browser would have? Is that right? My concern would be that since TiddlyWiki is allowed to write to the file system in a way that my browser cannot, TiddlyWiki might exasperate the issue. In other words can we "prove" that we are not vulnerable to this kind of attack?

Then the question becomes how can we convince NVD that's true.

[matthewweippert]

From NVD FAQ:

Mitre's page is a form where you can "request and update to an existing CVE", one option for the type of update includes "rejection" meaning "Vendor rejects the assignment of a particular CVE ID."

Has someone who can fairly claim to be "the vendor" filled out this form? If not, can you? Let's hope this goes better than @CrossEye's experience.

[matthewweippert]

I cannot confirm this myself, but the report says to

You can not confirm it, since nothing happens. ...

I know that for the 5.2.3 - 5.2.7 I happened to have around and tested. I didn't try to dig out a 5.2.2 ...

I pasted the svg above into my 5.2.2 TW running on Chrome in Ubuntu using timimi. Nothing happens inside the tiddlwiki, but if I right click and open a new tab I get, as predicted, an empty alert.

[Jermolene]

Mitre's page is a form where you can "request and update to an existing CVE", one option for the type of update includes "rejection" meaning "Vendor rejects the assignment of a particular CVE ID."

Has someone who can fairly claim to be "the vendor" filled out this form? If not, can you? Let's hope this goes better than @CrossEye's experience.

Thank you @matthewweippert, it would definitely be worth posting a rejection request.

I think the crux of the message would be that TiddlyWiki 5 is explicitly designed to allow authorised users to post arbitrary web content that is visible to other users, and so the ability to do so does not constitute a vulnerability.

Further, the CVE imagines a scenario where an attacker has the necessary permissions to upload/edit content on the system. In TiddlyWiki's threat model, hostile users are not given permission to upload/edit content.

I'd welcome assistance in drafting a suitably persuasive message.

[CrossEye]

I think the crux of the message would be that TiddlyWiki 5 is explicitly designed to allow authorised users to post arbitrary web content that is visible to other users, and so the ability to do so does not constitute a vulnerability.

It's more than that. There is a very specific test. The idea is to upload this SVG file, which consists just of

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">

<svg version="1.1" baseProfile="full" xmlns="http://www.w3.org/2000/svg">
   <polygon id="triangle" points="0,0 0,50 50,0" fill="#009900" stroke="#004400"/>
   <script type="text/javascript">
      alert(document.domain);
   </script>
</svg>

and then,

If this file is uploaded to a server and displays the alert box with the current domain after rendering, You have discovered a stored XSS

I tested when I brought this up, and just tested again with 5.2.7, on both tiddlywiki.com and on empty.html. You do not get the alert on upload, on viewing the uploaded tiddler, or on viewing it transcluded.. I also checked what happens if we change the type to text/x-tiddlywiki or text/html and there is still no alert.

In other words, this is nonsense, at least for 5.2.7. I haven't checked anything before 5.2.5, though. And I haven't investigated TW's image handling to see why this doesn't happen. But I did check a trivial HTML file with an image tag loading that and it didn't happen there either. It does happen if I embed the SVG into the HTML source, and I guess that is the attack vector: when arbitrary uploads can simple be embedded in HTML source.

[Jermolene]

Thanks @CrossEye, that's helpful. The chain of reasoning I was trying to communicate was that this is a particular case of an executable script upload, but that the whole class of executable script upload vulnerabilities don't apply to TiddlyWiki. But your logic is narrower: that the vulnerability as reported does not exist because (a) one has to open the image in a new tab to get the script to execute and (b) in any case the script doesn't have access to document.domain.

If that's right, perhaps both arguments can be given, starting with the narrow refutation and going on to the broader one.

[CrossEye]

Right. I think it's incumbent upon the reporter to demonstrate an actual vulnerability. In this case, the report is wrong. We can further argue that the design precludes any similar vulnerabilities, but that's icing on the cake.

I'd forgotten the "load in a separate tab" bit, but since we use a data: uri, we again have no such vulnerability.

I volunteered earlier to do this if there was no one else available to do so. And I'm still willing. But it probably would be better coming from you @Jermolene: I don't have deep enough knowledge to make the broader point. I'm just now to the point where I can answer as many questions on talk.tiddlywiki as I ask; while that feels good, it's still fairly superficial understanding. But if you don't have the time or inclination, let me know, and I'll add it to my ongoing battle with mitre. 😦

[Jermolene]

Hi @CrossEye perhaps we could collaborate on this, and then I'll submit it? You may be best placed to draw up a rough first draft, if you have experience of the context, if you can?

[CrossEye]

Sure. It may not be today, but I'll get to it in the next few days.

[Jermolene]

Thank you @CrossEye much appreciated.

[matthewweippert]

I agree with @CrossEye's approach. The CVE falsely claims that someone could, for example, post an update to Motovun Jack.svg with <script> and "execute arbitrary code" on my machine if I uploaded this into my TW. It might complicate the issue to point out that I could put that same script in an HTML tiddler.

Once a rejection request is posted, we might want to consider making that information more publicly available. By "that information" I mean both the CVE and why it's bogus. When I found the CVE, my first thought was to look at tiddlywiki.com, then https://github.com/Jermolene/TiddlyWiki5.

Let me know if I can help...

[joshuafontany]

Has anyone tested this on the TW node.js server? If not, that is where the vulnerability is. At that point, document.domain is not a local file pointer, it is a server url.

[Jermolene]

Has anyone tested this on the TW node.js server? If not, that is where the vulnerability is. At that point, document.domain is not a local file pointer, it is a server url.

Thank you @joshuafontany that's a great point. I can't run the tests today so I hope somebody else might be able to give it a try.

I'm still struggling to see where the vulnerability might arise. Access to document.domain doesn't seem on its own to be dangerous; as we've noted before, it's the same level of introspection available to JavaScript in HTML pages. I'm no expert on security, but wouldn't some means of accessing the JS or DOM of TiddlyWiki itself be required to do any mischief? Unless they class hosting arbitrary HTML/SVG content as a mischief vector, of course.

[CrossEye]

I just tested this on Node Server versions 5.2.2, 5.2.5, and a head version listed as 5.2.8-prerelease. I don't find the bug in any of them. This is clearly nonsense. I'll try to write up a response tonight.

I'm still struggling to see where the vulnerability might arise.

I think document.domain is just meant to demonstrate that this crafty uploaded image can run a script that has access to things in your runtime environment. Because $tw is global (like document), if this attack worked, there would be a pretty clear demonstration that such svg-embedded code could run a lot of TW-code, conceivably hijacking, say the decrypt plugin or something. Since it doesn't seem to work, I think we can (try our best to) explain that TW is simply not vulnerable to this.

[joshuafontany]

Thanks, I was away from my laptop & haven't fully re-setup my TW dev environment when that occurred to me.

[pmario]

This is the code SVG code I did test. with a TW v5.2.1 at: https://pmario.github.io/test/ and also https://tiddlywiki.com/prerelease/

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">

<svg version="1.1" baseProfile="full" xmlns="http://www.w3.org/2000/svg">
   <polygon id="triangle" points="0,0 0,50 50,0" fill="#009900" stroke="#004400"/>
   <script type="text/javascript">
      alert(document.domain);
   </script>
</svg>

Which creates an alert in a new tab with FF. But it does not have access to the original document URL. The document.domain text in the alret box is empty.

IMO every data-url from every web-page will be able to create this type of behaviour.

[CrossEye]

I'm not much of a video learner, so I probably hadn't watched the video. Now I can't, as it's marked as private. What a fiasco!

[joshuafontany]

Unless it's arbitrary code execution, and not document.domain specific. But, @jermolene's point that TW is not expected to allow unauthorized users to run code in authorized context is a clear response.

[CrossEye]

Here is my attempt at a simple response to the bug report:

Please reject this vulnerability.

This bug report is illegitimate. Tiddlywiki is not subject to the flaw. Although one can manage to execute script in a new window, as described, that script has no access to any user or server data. Its global context is that of a data: uri . The supporting evidence for this says

"If this file is uploaded to a server and displays the alert box with the current domain after rendering, You have discovered a stored XSS." (emphasis added)

But the video evidence demonstrates that in fact, no domain is shown. (The original video is no longer public, but it was captured by the wayback machine.) It shows an alert without the document domain value. The Tiddlywiki team has tested this in numerous configurations over many recent version and found no evidence of such a vulnerability.

If there is further information necessary, please let us know.

If that works for us, @Jermolene, please feel free to submit it. Feel free to tweak it, to edit it heavily, or to reject it altogether. You won't hurt my feelings. Depending on how you want to present it, you might want to change the last phrase from "please let us know" to "please let me know." I think it would be better coming from you, but if you've changed your mind about doing it yourself, I would be willing to submit it.

[Jermolene]

Great thank you @CrossEye I've submitted the response, and will update here if I hear anything back.

[CrossEye]

@Jermolene: Can I assume that no news is... no news?

[Jermolene]

Hi @CrossEye indeed, I haven't heard back from Mitre since I emailed our response on May 16th. I guess things don't move very quickly in these matters...

[Arlen22]

The bug is bogus, and the entire use case doesn't even apply to TiddlyWiki.

Even if they can import an SVG, they can't do anything unless they are also able to save the HTML page back to its original location, which makes them the webmaster, not an attacker. Any other user who uploads the SVG only uploads it to their own browser and never has access to the server.

There is never the remotest possibility of an XSS attack of any kind because if the attacker had the remotest possibility of getting the SVG onto the server, they would never have needed to use an SVG to do it at all. All the upload feature does is insert images into the webpage as part of the editing process.

The ability to upload files into the webpage during editing is a feature which is made safe by the fact that it occurs entirely in the browser and has no access to the server at all. There is no special consideration given to these kinds of file uploads over any other mechanism of entry. They are stored in the same way every other kind of content is stored, and with the same permissions.

Would this be a problem if...

... users were allowed to upload images SVG files to the webserver and have them displayed to other users? There are plugins which enable this.

In most cases the SVG file is included as a data uri in an HTML img tag. In an HTML iframe, the browser sandbox prevents the script because "allow-scripts" isn't set on the iframe. And in Tiddlywiki markup it uses the safe-script tag. So even in the hands of naive webmasters this is hardly an issue.

By default, TiddlyWiki only has two "roles": read-only and read-write. There is no special XSS scenario where users can upload images but don't have access to the entire site.

The security of third-party server plugins depends on those plugins, and not on TiddlyWiki.

... a webmaster or editor went rogue and decided to start inserting script tags?

Yes. But that would NOT have resulted in ANY security vulnerability report. Every website is always at the mercy of the person paying the bill to host the website. It's their decision who they choose to share that access with, just like the owner of a car chooses who they share the keys with. An "XSS attack" implies that you can drive the car without the keys, so to speak, which is simply not the case here.

OK, but does that mean we can't upload files?

No. You can still upload files. Just keep in mind that if you allow users to upload files then it is possible for them to insert script tags in SVG. So only allow users you trust to upload files.

But every kind of website has that problem. It can be an XSS attack vector and public uploads should always be properly sanitized before being shown to other users.

TiddlyWiki, as far as I know, makes no claims to fully sanitize all code thoroughly for every use case. It follows some standard practices, like using img data uris instead of directly include the xml in the page, but then it's up to the user's browser policies as well as the individual server settings.

If you don't understand the full security (and legal) implications, don't be letting the public upload images to your site and share them with other users.

[Arlen22]

In Plain English

The person hosting the HTML wiki file is the only person who can upload the SVG file.

On a server, only people with write access can upload SVG files.

TiddlyWiki does not allow public uploads by default. That is not an intended use case.

So this report is the equivalent of warning that cars are dangerous because drivers are able to steer them. It's literally that.

Every single website in the world has this claimed vulnerability!

This "security vulnerability" is absolutely not a security vulnerability, and the report is illegitimate.

[CrossEye]

Once again, still no news on this issue, @Jermolene?

It came back to mind because a colleague is dealing with a security tool giving critical flags to many apps he supports because a disputed and clearly spurious CVE. He thought my experience would help sort this out. Hah! My own experience is of radio silence, ineptitude, and possibly sheer malice on the part of Mitre. It drove me from doing open-source work for the better part of a year.

[CrossEye]

I did finally hear back from Mitre on another false vulnerability report. Their answer, in essence, was "Bugger Off".

[Jermolene]

Hi @CrossEye to nobodies surprise, I haven't heard anything else from them. Very discouraging insight into the process that is supposed to protect us all.

[CrossEye]

@Jermolene: My time is freeing up again to look into this and related issues. Before I do, though, has there been any change?

[Jermolene]

Thank you @CrossEye much appreciated – there haven't been any developments that I am aware of.

[matthewweippert]

I don’t know if this is related to the erroneous CVE entry or not. Microshaft 365 defender has flagged tiddlywiki.com as “Opening this website might not be safe.” This only occurs when clicking on a link inside an outlook email. (Please don’t say stop using MS BS - I do have a choice and you will only make me cry.)

Do we want to handle that here? or elsewhere?

[matthewweippert]

Update on the CVE. Approval to use this software on some systems is controlled by the “National Vulnerability Database” - The relevant link there is CVE-2022-29351. As of 08/03/2024 that was updated with status “disputed.”

[CodaCodr]

@matthewweippert I have work-related MS365, Outlook and Outlook PWA.

I sent mails from my gmail and my private outlook.com -- both containing links to https://tiddlywiki.com. Both worked flawlessly.

[Jermolene]

I don’t know if this is related to the erroneous CVE entry or not. Microshaft 365 defender has flagged tiddlywiki.com as “Opening this website might not be safe.” This only occurs when clicking on a link inside an outlook email. (Please don’t say stop using MS BS - I do have a choice and you will only make me cry.)

Do we want to handle that here? or elsewhere?

Hi @matthewweippert I am sorry you've been tripped up by that rogue CVE. It is a genuine report, but very, very misleading. It refers to a well known issue with uploaded SVG files. It only affects TiddlyWiki in very specific circumstances while using the Node.js configuration. And yet the way that CVEs work this issue gets smeared across the whole project. There are more details over at #7384

There may well be more that we can do to get this CVE recategorised or something, but it's not an area where I have much experience and so I would welcome help.