Bug#791467: plowshare: javascript usage puts user at risk of remote code execution

[plowshare4-bug@discard.email]

> 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.