Welcome! This is a community for all those who are interested in protecting their privacy.
PS: Don't be a smartass and try to game the system, we'll know if you're breaking the rules when we see it!
Some of these are only vaguely related, but great communities.
In related news, Microsoft is retiring support for inline SVG images in Outlook for Web and New Outlook (which is just Outlook for Web in a trenchcoat and should be killed with fire), because apparently removing functionality is easier than fixing vulnerabilities.
I expect Edge will also be dropping support for SVGs in the near future.
Why is SVG necessary for this? JS can be executed from HTML by itself; does putting it into SVG disable certain browser security features? I am a bit confused about this.
Generally, browsers try to make it very difficult for the contents of one website to read or interact with the contents of another website. There is a class of attacks called cross site request forgery (CSRF) where website A tries to trick the browser into sending a web request to website B and performing some action which requires authentication. In this case, the action would be to like a Facebook post.
Imagine something really basic like your bank has an endpoint GET shite-bank.com/account/transfer?funds=100&to=myEvilAccount. Website B could try and redirect you to that URL. If you're logged in to shite-bank, then when that request completes you will transfer 100 funds to me. Generally, most websites use various techniques and tokens to prevent other websites from triggering requests like this.
I clicked through the source article, and it sounds like this is specifically a windows thing: original article says that when a windows machine loads the malicious SVG, the malicious JS is parsed in a Microsoft Edge browser process, regardless of the browser a user visited the porn site with (apparently all Windows SVGs load through Edge). I would guess that there is some aspect of this context switch which enables the CSRF attack to work, but it is not explained in the original article.
I clicked through the source article, and it sounds like this is specifically a windows thing: original article says that when a windows machine loads the malicious SVG, the malicious JS is parsed in a Microsoft Edge browser process, regardless of the browser a user visited the porn site with (apparently all Windows SVGs load through Edge).
what the actual fuck? does that mean that even if I only use firefox, edge is involved in loading SVGs? how??
Opening the SVG file opens an empty Edge tab titled Process Monitor. This happens because SVG files on Windows are opened by Edge, even if the user has another browser set as their default.
that does not explain how does it happen when the svg appears on a page in firefox. firefox won't try to open all embedded assets with the default file handler in the OS, it will directly use its built in tools to handle it.
I think it's saying that the default association for SVG is edge, as setting a default browser does not change that. If you use another image viewer for SVG it might behave differently.
but how does edge get opened? firefox, and pretty sure chrome too, aren't searching the OS file associations for each asset they received from the site. they won't decode the png images with Windows Photos or whatever, they will use their internal tools to process it.
file associations would only affect if you open an svg file in the filesystem with a file manager. but I don't see how edge gets into the picture when the user is just using another browser, because it's rare that a user saves an SVG
I found this technically surprising, but like the most microsoft thing ever.
Unlike more common formats such as .jpg or .png, .svg uses XML-based text to specify how the image should appear, allowing files to be resized without losing quality due to pixelation. But therein lies the rub: The text in these files can incorporate HTML and JavaScript, and that, in turn, opens the risk of them being abused for a range of attacks, including cross-site scripting, HTML injection, and denial of service.
Willing to bet that some browsers just do what the SVG says.
Yes, you are just quoting the article which I already read, but this fails to answer the question why the same JS does something different depending on whether it is part of an SVG or not. Should it not be possible to put the same JS directly into the HTML?
The SVG is probably parsed by a different library or different module at least and might have exploitable bugs. Still, the js would likely be fed to the same engine. It might not be impossible that something gets mangled or the context is different.
But mostly this smells like a fantasy article. No mention of which exact browser, what the mechanism is and, in particular, no sample code. And as a bonus the bs blanket term of "adult sites" which makes this look more like fear propaganda.
I don't know* jack about shit but I got fud vibe from this headline lol
Gooners get punished for watching content!
svg are treated the same as webpages by modern browsers. Either integrated into the dom directly, or as a sort of sub page. Not much potential for exploits you couldn't do in html.
This should mostly be about injection, so someone else uploading a picture to a page and taking it over for other users. Just loading that image might make your account follow some profile there, or even do some action like press a share button.
That might make sense, but the article doesn't really indicate that that is what it means.
risk of them being abused for a range of attacks, including cross-site scripting, HTML injection, and denial of service.
But CSS and DoS would require the underlying implementation of JS to be capable of those things. Maaaaaybe you could argue DoS, but CSS should be impossible for any site properly implementing CSRF and content policy protections.
xss not css. css are the style sheets :)
But yeah, the article isn't very clear on what it means.
dos I could see via just provoking a ton of same domain requests in the svg, like loading a lot of images from the same domain. Then every user seeing it would take part in dosing that page.
XSS could mean data exfiltration, which should still pass most restrictions currently.
Would data exfiltration work, though? I forget exactly what the header value is, and am far too lazy to look it up right now, but I'm pretty sure there's a standard one that lets a website define where requests should be allowed to point at. Unless they're scraping the data themselves, but then that hardly needs malicious JS.
Only an idiot parses an image file as executable code.
I can't tell if you're being serious or just making a joke.
It works both ways, which ultimately is the issue.
A well created malicious exploit will look like an image (or any other file) to a user, but can execute arbitrary code.
That's why I thought maybe you were just making a joke.
Sure but that requires the given parser (the web browser, the image lib, etc) to arbitrarily run code in the first place. Which... well, why? It's an image, not a program. Treat it as an image. Hence "only an idiot" writes an image parser to actually execute an image (same with eg.: only an idiot would write an MP3 parser that arbitrarily executes an MP3).
Even if an SVG had JS in it, as an image-proccessing lib the correct method would be not to try to run the JS in your SVG by yourself but rather just hand it down to whoever is processibg JS at the moment (which would be, well, the browser context and its sandbox).
I don't think you understand how exploits work. We're not talking about "running JS in an image viewer".
https://blog.cloudflare.com/inside-imagetragick-the-real-payloads-being-used-to-hack-websites-2/
that requires the given parser (the web browser, the image lib, etc) to arbitrarily run code in the first place
At the most base level, every image is data, and any data can theoretically be code. The image's data has to be parsed (like you said) and the parser can be exploited to trigger code execution.