From ${URL} : In anki, cards are formatted using HTML and displayed using a web browser control. The browser is not appropriately restricted against script injections. Attacker can execute scripts by inserting those into card template, as well as accessing arbitrary local and remote files. Reproducers: <a href="javascript:alert('Test')">click</a> -> script execution <img src="file:///path/to/local/file"/> -> local file access <img src="http://example.com/path/to/remote/file"/> -> remote file access @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
Does upstream know about this? I can't see any indication that somebody has reported it.
(In reply to Thomas Kahle from comment #1) > Does upstream know about this? I can't see any indication that somebody has > reported it. reported upstream: https://anki.tenderapp.com/discussions/ankidesktop/15320-security-issues-with-the-anki-browser I have no account on Fedora bugzilla. It would be good if somebody could link it there too.
https://anki.tenderapp.com/discussions/ankidesktop/15320-security-issues-with-the-anki-browser#comment_41757644 > This has been fixed in the alpha builds - we serve all media content over > a local socket and local file access is not allowed. I requested information about the first version introducing this change.
i'm not 100% sure about the version, but going by the response, i think it's fixed in the 2.1.0 series (which hasn't had a non-alpha release yet)
Posted on their system ______________________________ Any chance you can pull this in to the main line build 2.0.X to fix the security problem. As I do not know your plans, but 2.1.X is probably not going to go live for some time and it is a good idea to fix a security bug that has been around since 2015.
Ok got a reply: There are some problems preventing this I'm afraid. Some users use file:// URLs in their collections, and I'm not sure we should be breaking that functionality in a point release. And as mentioned in a post above, it doesn't seem to be possible to control local file access in conjunction with setHtml() - the alphas are relying on the fact that WebEngine behaves differently to WebKit when local HTML is injected. ______________________________ So I guess we are stuck waiting for alpha to become production, unless you would like to do something else.
(In reply to SpanKY from comment #4) > i'm not 100% sure about the version, but going by the response, i think it's > fixed in the 2.1.0 series (which hasn't had a non-alpha release yet) 2.1.0_beta27 is in ::gentoo now and <2.1 is masked for removal due Qt4, so this one will go away.
Package is unstable now.
