Bug#791467: plowshare: javascript usage puts user at risk of remote code execution
I am in the process of packaging the new upstream version of plowshare. There has been a significant change so that the core framework (of shell scripts) is kept entirely separate to the scripts which use this API to implement support for specific external sites. While separating the core from the scripts that support the individual sites is definitely a step in the right direction, I think that relying entirely on audits of those scripts is a bad idea. There are many such scripts, new scripts for new cyberlocker sites are frequently added, and existing scripts updated to take account of changes to the sites they support. Therefore, performing such audits would be like playing a game of whack-a-mole. Moreover there is a trade-off: the stricter the scripts are about what javascript they accept, the more likely they will be broken by small changes so the websites. Lastly, you've got to wonder how effective malicious code detection can be if it's implemented entirely using unix shell tools (and presumably operates purely on the syntactic level). For these reasons, you really do need a sandboxed javascript interpreter if you want to avoid the possibility of malicious code execution. Maybe other js interpreters (v8, spidermonkey) are easier to sandbox? Until you find a way of sandboxing the JS interpreter, I'd recommend disabling the javascript support.
Bug#791467: plowshare: javascript usage puts user at risk of remote code execution
Yes, this is exactly what I'm doing if you take a look at the blocking bugs for this present bug. I've patched the package to remove javascript support and I'm waiting on a mentor to upload to unstable and then approval to upload to stable. I'll work out if there is a viable alternative fix in the future. Carl
Bug#791467: plowshare: javascript usage puts user at risk of remote code execution
Ok, this is my first package in debian so I'm still getting used to things. My thinking is that this package depends on external APIs (the hosting websites) and so it is a good candidate for backports. I hope to be able to add new upstream versions there in addition to unstable. I know that version 2 doesn't handle javascript differently, but it does have a different philosophy about modules and who is responsible for them, so I want to think about what is reasonable with that situation. I see that rhino in stable has a -sandbox switch. I know very little about rhino, and I'll have to check to see exactly what promises this mode makes, but it might be sufficient. The documentation is very vague so I'm not confident about this. As for the version of plowshare in stable: it will become increasingly irrelevant as the API implementations gradually break. I would expect that anyone making serious use of it would be after the latest versions anyway rather than relying on the stable version. As such, disabling the javascript support entirely is probably acceptable and is certainly the most definitive fix. I expect it to at least partially break something of order 10 modules, but I'll test out this solution shortly. Carl -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#791467: plowshare: javascript usage puts user at risk of remote code execution
Hi, On Mon, 06 Jul 2015 11:42:55 +1000 Carl Suster c...@contraflo.ws wrote: I am in the process of packaging the new upstream version of plowshare. There has been a significant change so that the core framework (of shell scripts) is kept entirely separate to the scripts which use this API to implement support for specific external sites. Once this new version is available in the archives (it will have to go through the NEW queue because of the split into separate packages), I will be able to audit the code more carefully and isolate any javascript snippets. Hence I'll defer addressing this bug until the new package is ready. plowshare4 is part of a stable Debian release so the new upstream version won't help there. There doesn't seem to be a difference between version 1 and 2 on how Javascript is handled anyway. The modules parse Javascript code from a website and call javascript() which is located in core.sh. That leaves two options: 1) Figure out how to make rhino run the javascript code in a sandbox. 2) Add a patch to disable Javascript code evaluation (probably breaking some modules). Felix -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#791467: plowshare: javascript usage puts user at risk of remote code execution
Package: plowshare4 Version: 1.0.5-1 Severity: grave Tags: security (Rationale for severity grave: introduces a security hole allowing access to the accounts of users who use the package. plowshare4 is a command-line tool for downloading files from cyberlocker-type sites. For some sites, this requires evaluating snippets of javascript code, to this end the plowshare4 package depends on rhino, a JVM-based javascript implementation. According to the rhino documentation, the rhino command-line tool is capable of loading arbitrary java classes, accessing the filesystem and executing shell commands (see https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Rhino/Shell ). This has obvious security implications: If the individual plowshare4 download modules are not carefully implemented, a malicious download site could emit javascript code which causes arbitrary commands to be run on the user's system. Where the javascript is downloaded via http rather than https, a malicious 3rd party (man-in-the-middle) could do the same. In order to prevent this, the javascript interpreter should be invoked in such a way that the code is evaluated in a sandbox, i.e. loading arbitrary java classes, accessing the filesystem and executing shell commands are not possible. There does seem to be some support for this in rhino, judging by the documentation https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Rhino/Overview#Security Moreover, the javascript code snippets should be filtered to check for malicious code before being passed to the javascript interpreter; ideally, any code that doesn't match a specific, known-good pattern should be rejected. Until these things have been implemented, I suggest disabling javascript support in plowshare4 completely to prevent putting users at risk.
Bug#791467: plowshare: javascript usage puts user at risk of remote code execution
I am in the process of packaging the new upstream version of plowshare. There has been a significant change so that the core framework (of shell scripts) is kept entirely separate to the scripts which use this API to implement support for specific external sites. Once this new version is available in the archives (it will have to go through the NEW queue because of the split into separate packages), I will be able to audit the code more carefully and isolate any javascript snippets. Hence I'll defer addressing this bug until the new package is ready. signature.asc Description: OpenPGP digital signature
