Author Topic: Adding .svg to allowed attachment file types? (Read 6523 times)

Nominal Animal · « **on:** February 23, 2022, 04:48:23 am »

Would it be possible to add .svg to the allowed upload attachment file suffix list?
I do not think it is necessary to add any extensions to the SimpleMachines Forum software, just add the file suffix to the allowed suffixes' list.

Current browsers support SVG files just like PNG, GIF, and JPEG images. SimpleMachines Forum also supports SVG images; it just does not allow uploading .svg files as an attachment.

Consider Larry Ewing's classix Tux logo, a 94015 byte SVG file:

which is displayed above using [img]https://www.nominal-animal.net/answers/tux-by-larry-ewing.svg[/img] .

(If one removes the width and height attributes of the target SVG file SVG element, only leaving the viewBox attribute, the SVG image will naturally scale to the maximum size possible in the allowed space, see e.g. https://www.nominal-animal.net/answers/tux-by-larry-ewing-unsized.svg.)

Inkscape is an easy to learn application for creating, editing, and manipulating SVG files, and is freely available for basically all operating systems, but all vector graphics packages nowadays do support SVG.

Diagrams, including circuit diagrams, are better described in vector graphics formats like SVG: file size should be smaller, and visual fidelity much better. Many free web tools like EasyEDA do allow easy export in SVG form, too.

I myself put the images on my own web site, and just link to them (as shown above), but I think it would make sense to allow SVG file uploads as normal image attachments, too. It would help with both image fidelity and file size (using less server resources).

emece67 · « **Reply #1 on:** February 23, 2022, 06:27:46 am »

Berni · « **Reply #2 on:** February 23, 2022, 06:36:03 am »

I agree the SVG format is one of the best vector graphics formats out there. It is well supported by software, does not break so easily from one software to the next, no huge amounts of legacy baggage, no big corporation pushing the format.

The only other widely usable way to send vector graphics is PDF but i had that go wrong in so many ways.

magic · « **Reply #3 on:** February 23, 2022, 09:17:46 am »

Quote from: Nominal Animal on February 23, 2022, 04:48:23 am

Consider Larry Ewing's classix Tux logo, a 94015 byte SVG file:

Quote from: Nominal Animal on February 23, 2022, 04:48:23 am

Diagrams, including circuit diagrams, are better described in vector graphics formats like SVG: file size should be smaller

April Fools is next month

I don't necessarily disagree with the proposal, but you picked a wrong example, perhaps.

Ian.M · « **Reply #4 on:** February 23, 2022, 09:28:57 am »

Unfortunately allowing SVG files without a robust server side SVG validator and malware scanner would permit cross-site scripting attacks to be hosted at EEVblog, so its not as simple as just adding .svg to the permitted extension list.

See: https://www.fortinet.com/blog/threat-research/scalable-vector-graphics-attack-surface-anatomy

magic · « **Reply #5 on:** February 23, 2022, 09:43:59 am »

Quote

Scalable Vector Graphics (SVG) is an XML-based vector image format for two-dimensional graphics with support for interactivity and animation. The SVG specification is an open standard developed by the World Wide Web Consortium (W3C) since 1999.

Nevermind, you have changed my mind. It's pure evil

Correct me if I'm wrong, but it's not just that malicious SVG could be hosted on the forum, but merely permitting SVG files to be embedded by [img] tags enables attacks hosted at nominal-animal.net to be executed on this forum's visitors. Is the whole thing really that braindamaged?

edit
Embedding SVG by <img> tags which is what the forum [img] tags do is supposed to disable the most dangerous features of the format. So mere embedding from other sites may be OK if you trust browser implementations to handle this mess right.

Berni · « **Reply #6 on:** February 23, 2022, 10:32:33 am »

Wait you can just stick javascript into SVG and it simply executes!? Why would a vector graphics format need scripting and intractable elements? What idiot thought that was a good idea

Okay yeah, SVG is a terrible idea in that case.

So... once again we are back at PDF garbage as the most universal vector graphics format.

magic · « **Reply #7 on:** February 23, 2022, 10:41:02 am »

Depending on what software renders it, and depending on how the image is embedded when it comes to HTML, yes, that's exactly what can happen.

PDF also supports embedding MalwareScript code.

Berni · « **Reply #8 on:** February 23, 2022, 10:44:40 am »

Ah great...

So what is left there as vector formats? DXF? I think the 1980s just called that they want there format back... at least back then they didn't have 20 different versions of the format while most software only reads 1/8th of said versions.

Ian.M · « **Reply #9 on:** February 23, 2022, 10:49:53 am »

Quote from: magic on February 23, 2022, 09:43:59 am

edit
Embedding SVG by <img> tags which is what the forum [img] tags do is supposed to disable the most dangerous features of the format. So mere embedding from other sites may be OK if you trust browser implementations to handle this mess right.

How locked down is *YOUR* browser? Mine is more locked down than average but eevblog.com is on the whitelist, so I *really* wouldn't like malicious SVGs to be hostable here in case the black hats come up with a new SVG exploit for it. Exploits on sites not on my whitelist don't bother me so much as the chances of anything getting executed are, for me, much smaller. Of course if you've 'drunk the advertising and social networking kool-aid' you are probably running a 'vanilla' install of a popular browser so are wide open to any zero-day exploits.

Also, permitting .svg attachments will attract *MORE* spammers and self-desribed '1337 hAcK3rZ'.

Nominal Animal · « **Reply #10 on:** February 23, 2022, 01:14:00 pm »

Quote from: Ian.M on February 23, 2022, 09:28:57 am

Unfortunately allowing SVG files without a robust server side SVG validator and malware scanner would permit cross-site scripting attacks to be hosted at EEVblog, so its not as simple as just adding .svg to the permitted extension list.

Crap, forgot about that. I think this came up before, either here or in some other forum.

One robust method would be to reject all SVG uploads that contain "<!ENTITY", or script or foreignObject elements (including in explicit named XML namespaces). For SimpleMachines 2.0.x, this is a simple addition to Sources/Sub-Post.php:createAttachment() just before security checks for images, and therefore a rather simple modification to SMF.

That does nothing to the Billion laughs attack (a recursive self-reference), though. Many applications use the <use xlink:href="#id" ... /> element pattern, so the only reliable way to filter those out is to test-render the SVG image, for example to create a thumbnail image. If it has any shenanigans like that, the upload will fail. (If an external program is used with strict process memory and runtime limits, it'd be bounded and fast, too.)

Note, however, that anyone can do the Billion laughs attack right now anyway, by using [img]url-to-nasty-svg[/img], so I'm not sure if trying to protect against it makes any sense. Also, the equivalent attack for Zip files (zip of death) is not defended against either.

Hmm, perhaps I should post the needed changes as a patch, upstream, because they already have (some) SVG support enabled? That way it'd help all SMF 2.0.x users, not just a single site.

thm_w · « **Reply #11 on:** February 23, 2022, 10:04:52 pm »

Quote from: magic on February 23, 2022, 09:17:46 am

I don't necessarily disagree with the proposal, but you picked a wrong example, perhaps.

Transparency was lost though, although that is rarely useful here.

magic · « **Reply #12 on:** February 23, 2022, 10:50:16 pm »

Because it's a screenshot from the forum

GIF and PNG both support transparency if they want to.

OTOH, I just noticed that the beak came out posterized after GIF encoding

Well, I could have uploaded PNG which is 24 bit lossless and still half the size of the original XML blob

magic · « **Reply #13 on:** February 23, 2022, 11:07:01 pm »

BTW, I have no idea about real world efficiency of SVG. I mean, it's uncompressed XML

so it cannot be great, but it's not a dumb bitmap format OTOH.

That being said, GIF isn't too bad either. Here's a real world schematic with almost 100 components in 32KB GIF.
https://www.eevblog.com/forum/projects/opamps-die-pictures/?action=dlattach;attach=1190312;image

Produced from the ASC vector format

The schematic is 16KB plus definitions of all the symbols (~500 bytes per symbol so maybe ~3KB total).

I guess SVG fanboys can upload something of comparable complexity to support their case

Nominal Animal · « **Reply #14 on:** February 24, 2022, 05:21:15 am »

The reason I included Tux, is to show that it works on all browsers, even for complex images. It is not just vector graphics, but uses SVG filters and other advanced functions.

By replacing the width and height attributes with viewBox attribute in the SVG element in the file, you get a perfectly scaling version. See e.g. https://www.nominal-animal.net/answers/tux-by-larry-ewing-unsized.svg (92k), especially if you have a 4k display.

Compare to magic's GIF image, which on my display is quite mushy around the letters and quite blocky at the diagonal lines. It works, but isn't nice.

Quote from: magic on February 23, 2022, 11:07:01 pm

I guess SVG fanboys can upload something of comparable complexity to support their case

Berni · « **Reply #15 on:** February 24, 2022, 06:18:35 am »

Seams like vector formats in general are security nightmares.

The next commonly supported vector file is WMF/EMF. It is also widely supported by vector drawing software and was not limited to Windows as it was originally designed for it. It would render in browsers just fine for a while but all popular browsers have dropped support for it due to..... yes once again remote code execution exploits.

PDF has vulnerability issues too but it is so widespread that it is impossible to kill the format now.

This is getting ridiculous, is there ANY vector format out there that is not full of security holes? (Apart from annoying ones that need special software to open where people likely don't even look for holes because they are too obscure)

Ed.Kloonk · « **Reply #16 on:** February 24, 2022, 06:32:10 am »

Quote from: Berni on February 24, 2022, 06:18:35 am

Seams like vector formats in general are security nightmares.

The next commonly supported vector file is WMF/EMF. It is also widely supported by vector drawing software and was not limited to Windows as it was originally designed for it. It would render in browsers just fine for a while but all popular browsers have dropped support for it due to..... yes once again remote code execution exploits.

PDF has vulnerability issues too but it is so widespread that it is impossible to kill the format now.

This is getting ridiculous, is there ANY vector format out there that is not full of security holes? (Apart from annoying ones that need special software to open where people likely don't even look for holes because they are too obscure)

The thing to watch is the remote code execution enablization. I'm surprised the cathedral doesn't keep more of an eye on this. It's always after the horse has bolted. Then they say Hey! you shouldn't have done that!

Berni · « **Reply #17 on:** February 24, 2022, 07:58:03 am »

Well it is one thing when they find a specific crash inside the software that renders the file. Like setting the length of some data block as negative that then causes the parser to crash in just the right way to lead to image data being executed as code. The vector formats are much more complex than bitmap formats since they have to represent much more than just an array of pixel values. This is more of the reason why WMF is vulnerable since it is simply a fancy list of windows graphics API calls that can be passed silly parameters with no checks at all. The format was meant for exchange between applications on the same machine anyway, so for that intended use it was not vulnerable since the application tricking it into the malicious API call could just make the call itself without the help of WMF. But this morphed into an actual portable file format where this is a problem. But you could create a more robust parser for that.

The SVG thing is worse. They are working on creating a format that is specifically designed to be easily shared between people over the internet and even be supported by web browsers. Then during that someone goes "You know it would be great if this format designed for storing pictures could also contain any valid javascript code and make requests into the internet" and nobody brings up any concern about that. Why does a image format need such capabilities in the first place.

Just do one thing and do it well. Just take a look at PNG, it ticks all the boxes without any unnecessary crap. The format can represent any pixel format under the sun be it Grayscale, RGB, CYMK or any weird collor mapping, can do pelleted colors like GIF, can do proper transparency better than GIFs binary transparancy, can do animations just like GIF, does better compression than GIF, includes space for metadata (unlike the hack JPEG needs to just tack it on after the file ends), like JPEG it can be progressively loaded and still shows an image if corrupt. Perhaps the only thing missing is lossy compression support for photos, but we already have JPEG doing a great job at that, so does not try to solve a solved problem.

Nominal Animal · « **Reply #18 on:** February 24, 2022, 08:25:55 am »

Additional testing, for those interested:

The red and blue areas below contain a trivial cross-site scripting test. If your browser allows cross-site scripting across domains, the red and blue areas, when clicked, will pop up a prompt (JavaScript Alert) saying "red" or "blue".

Mine (Firefox 97.0 on x86-64 Linux) does nothing, unless the above image is hosted on the same domain as the page it is shown in.
HTML and foreign object inclusion only occurs within the SVG image area. It does not "leak" outside the image rectangle.

The tiny little link in the green area is a HTML link, that if clicked, pops up a JavaScript alert saying "link", if scripts are allowed within the HTML fragment inside the SVG image. Mine does not.
XML entity references are only effective within the SVG image itself. They do not affect the interpretation of the HTML code where the SVG image is displayed.

Aside from making SVG images so complex or recursive that they can be used for denial-of-service, I believe that using SVG images from a different domain is actually safe on current browsers. At least, on my browser, the abovementioned security issues (aside of too-complex/too-recursive SVG files) do not occur, if the SVG image displayed is hosted on a different domain.

This means that it is may not be a good idea to allow SVG attachments at this time, except if the upload is to a different domain, say an image or file hosting service.

If you do load the example page containing the two above images, you can test how the behaviour of the images differ when they are hosted in the same server/domain as the HTML page itself. However, on my browser, the abovementioned security issues do not occur: even on the same server, the SVG images behave as if they were in a different domain! Only when you open the SVG images themselves directly in your browser (first, second), can I get the JavaScript to function.

Simply put, the browser I use is secure against cross-site scripting via SVG files, even if those SVG files include HTML objects. If everyone used similarly protected browsers, there would be no danger in using SVG files.

If you want to try what the million laughs attack (million circles in an SVG file) does to your browser, at your own risk, you can try https://www.nominal-animal.net/answers/this-tries-to-crash-your-browser.html or just the SVG image itself, https://www.nominal-animal.net/answers/this-tries-to-crash-your-browser.svg.
We can only hope browser developers add some run-time limits on how long they're willing to burn CPU time to render just a single image.

magic · « **Reply #19 on:** February 24, 2022, 09:06:35 am »

Yes, because you are embedding with <img> tags. If you open either file directly, the embedded MalwareScript starts to work

(There are also more dangerous embedding methods which were common in the past because browsers didn't support <img>).

I found a crude python script converting ASC to SVG. There is something not quite right with this file because different software displays it differently and neither is 100% right.
It does scale better, but 175KB - that would be a few megapixels in GIF

Quote from: Nominal Animal on February 24, 2022, 05:21:15 am

Compare to magic's GIF image, which on my display is quite mushy around the letters and quite blocky at the diagonal lines. It works, but isn't nice.

That's the LTspice renderer for you. None of that antialiasing rubbish.

Maybe the answer is to write a MalwareScript ASC renderer akin to MathJax. ASC shows itself to be a very efficient format for line drawings.

Nominal Animal · « **Reply #20 on:** February 24, 2022, 09:30:03 am »

Quote from: magic on February 24, 2022, 09:06:35 am

Yes, because you are embedding with <img> tags.

Well, that's the point of using SVG files instead of GIF/PNG/JPEG on a discussion forum, innit?

What we need, are browsers that are designed to work for users, instead of advertisers.

As is, Firefox only needs a timeout for cumulative maximum time per page load when rendering SVG images to its internal surfaces, and it would be robust against nefarious SVG files. Right now, a specifically crafted recursive SVG file can stop a page from being displayed, but I couldn't get it to crash.

I would say the abovelinked SVG attack surface report from Fortinet isn't exactly up to date.

magic · « **Reply #21 on:** February 24, 2022, 09:42:07 am »

I wonder if one could put a crypto miner in SVGs to monetize on those who open them in a new tab to take a closer look

Nominal Animal · « **Reply #22 on:** February 24, 2022, 10:07:26 am »

Quote from: magic on February 24, 2022, 09:42:07 am

I wonder if one could put a crypto miner in SVGs to monetize on those who open them in a new tab to take a closer look

A JavaScript one would work, but only if it did the heavy lifting in a timeout (otherwise the browser will kill the thread for consuming too much CPU time).

And, since the user would open the SVG file directly in their browser, they could also press Ctrl+U to see its source code, revealing the crypto miner also.

SVG images can by the way be compressed using gzip. It only requires that the server, when serving the compressed SVG file (.svgz), uses the "Content-Encoding: gzip" HTTP header. The browser then decompresses it while downloading, transparently, as it would e.g. static HTML and other files as well when gzip-encoded. On the client side, the SVG appears as normal non-gzipped file, too.

magic · « **Reply #23 on:** February 25, 2022, 08:35:58 am »

Or simply permit SVGZ uploads and keep SVG banned

BTW, screw mining, it's inefficient as hell. Do you think it would be possible to use AJAX code in SVG to change the viewer's forum email address and password bypassing CSRF protections and request ransom?

Nominal Animal · « **Reply #24 on:** February 25, 2022, 09:27:51 am »

Quote from: magic on February 25, 2022, 08:35:58 am

Do you think it would be possible to use AJAX code in SVG to change the viewer's forum email address

Using my browser, no.

What you can do, always, is create a lookalike phishing site. You can make that static, or dynamic. If you get the user to open an SVG image as a page, you can make the image look like a web page, with normal web page interactivity. If you display that SVG image in an <img element, my browser disables the interactivity; it is then just an "almost-realtime thumbnail" of that web page.

If you put a phishing site on your own server, you can work around cross-site request forgery protections, too. The idea is that part of your server acts like a reverse proxy for the target site (both Apache and Nginx support this out of the box). Then, the phishing site uses site-local URLs for those resources. If you pay someone at a certificate authority to give you a fake certificate for www.eevblog.com, you can do man-in-the-middle invisible phishing. Of course, this has nothing to do with SVG, and everything to do with how browsers handle security.

Which, by the way, hasn't really evolved at all in the last quarter century. We have IEEE 1363.2 and zero-knowledge password proof since 2008. Practical PAKE has existed as long as the web itself has. Password inputs are already special, and browsers have all the needed public-key cryptography stuff to implement these; nothing outside the user and the ZKPP facility actually needs access to the password field itself. But no, we instead get browser developer summits where after long deliberations, the key decision is "We declare every charset except UTF-8 to be legacy character sets. Because UTF-8 is not a legacy character set, users should not be able to select it as the default character set." and similar inanities.


EEVblog Main Site	EEVblog on Youtube	EEVblog on Twitter	EEVblog on Facebook	EEVblog on Odysee

Author Topic: Adding .svg to allowed attachment file types? (Read 6523 times)

Share me