I agree that there are a lot of possible open “attack vectors”, and keeping track of every one is not feasable.
Good conversation so far. I think the primarily concern is that TW will run obfuscated javascript without a refresh required. That should have an option to “Sandbox” that behaviour somehow, and let superusers unlock it.
Thanks for the discussion!
Best,
Joshua Fontany
Thanks all for considering this;
I think the best way to limit risks is to provide plugins in trusted libraries, from trusted sources. then people could also install these in an empty html and run a vulnerability test using a plugin designed to highlight risks. As soon as a library contains something doggy the community can react.
To facilitate this I would like an easy way to collect and publish a library from a single file wiki, then the well known and trusted people can publish libraries that they themself can check or anyone in the community. Libraries contain plugins frozen in a moment of time, Only libraries so tested would be listed publicly. With all other sources the designer can run a (latest) vulnerability test published on tiddlywiki.com and if we must we can blacklist or whitelist plugins or “signatures” in this vulnerability tester.
In another discussion I am also calling for a hash tool which although not invulnerable would add another layer of testing, mostly to see which system tiddlers have being modified, and this would just make cheating more difficult.
The power we have on our side is the community and the ability to collect and centralise data in a way that “outsiders” have more work to do before they can compromise anyone to a large extent, ie make it harder and cause diminishing returns. We can also ensure we have trusted sources and be able to test them. In this light we may even benefit from people hacking, because we can identify the vectors and respond.
But finally I want to reinforce in many wiki editions or personal on my desktop/mobile only, I do not want features crippled, diminished or destroyed for when the wiki may be placed on an internet facing editable platform. This is why I think the vulnerability test tool has the greatest value. Horses for courses.
Regards
Tones
Just to make sure I’m understanding correctly: That particular attack wouldn’t yield much fruit, would it? The attacker would have an encrypted version of TiddlyWiki only xe could access, but the original user would still have the version xe opened on xir local hard drive or the Web site xe loaded the page from in the first place. All that would be encrypted for ransom would be the session-specific instance of that file, not the source file (which the browser can’t encrypt and save over on the fly).
Or am I misunderstanding?
@Scott,
With a bit of creativity, practically anything is possible! You’re right in that the JS could not have DIRECT access to the user’s file system, but as explained in
https://nakedsecurity.sophos.com/2016/06/20/ransomware-thats-100-pure-javascript-no-download-required/, one could simply use JS to connect to a server to install a malicious exe, which it could then run.
Essentially, the JS could easily apply a cipher to the file to thus “encrypt it”, and use the exe to rewrite the file content with this encrypted text.
The exe could also handle deletion of backups, or pretty much anything else needed.
Super-interesting stuff! Thanks for the background.
There’s a bit of consolation in there, though: It sounds like the RAA attack relies on getting the user to execute JS in the WSH rather than within the browser. TiddlyWiki on Node or running through Bob.exe or in TiddlyDesktop might be a more vulnerable vector of infection than a TiddlyWiki running the latest version of a Chromium-based browser. I’m not sure how those platforms compare to browsers when it comes to sandboxing the environment where scripts are executed.
The novel path of attack (sharing a .JS via tiddler with another TiddlyWiki user) is certainly worth considering as a potential vulnerability — but, as Tony said above, the balance between usability and security is often more nuanced than just locking down everything to prevent any possibility of infection.
This could be a great opportunity for some security-minded TiddlyWizards to come up with a script-vetting plugin to throw up red flags during the import of outside content. Maybe there’d even be a way to leverage malware databases via API to keep it up to date on current threats. That’s all way above my head, though, and maybe be as great a can of worms as trying to lock down TiddlyWiki to protect it from rogue JS.
With a bit of creativity, practically anything is possible! You’re right in that the JS could not have DIRECT access to the user’s file system, but as explained in
https://nakedsecurity.sophos.com/2016/06/20/ransomware-thats-100-pure-javascript-no-download-required/, one could simply use JS to connect to a server to install a malicious exe, which it could then run.
Essentially, the JS could easily apply a cipher to the file to thus “encrypt it”, and use the exe to rewrite the file content with this encrypted text.
The exe could also handle deletion of backups, or pretty much anything else needed.
Hmm that article is about tricking users into double-clicking on .JS files so that they run under the Windows Scripting Host, and doesn’t really cover the situation of TiddlyWiki.
Best wishes
Jeremy