X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/d60c829475123ddb6d258341c270160e4744604a..4729ff0812c1f3d06d98524e2fec232d3bf90513:/doc/plugins/contrib/bibtex2html/discussion.mdwn?ds=sidebyside diff --git a/doc/plugins/contrib/bibtex2html/discussion.mdwn b/doc/plugins/contrib/bibtex2html/discussion.mdwn index 60fccff9e..3e4207e4e 100644 --- a/doc/plugins/contrib/bibtex2html/discussion.mdwn +++ b/doc/plugins/contrib/bibtex2html/discussion.mdwn @@ -35,3 +35,104 @@ Right now, it is not possible for the [[plugins/contrib/compile]] plugin to rend >> individual vulnerabilities there involved ImageMagick and GraphicsMagick >> running arbitrary shell pipelines from delegates.xml that turned out not >> to be hardened against invocation by a hostile user. --[[smcv]] + +>>> The `exec` plugin would definitely not be marked as "safe": it +>>> allows wiki administrators to execute arbitrary code as the wiki +>>> user. +>>> +>>> That said, I believe it is possible to craft a configuration that +>>> *would* be safe to use for *users* in general. Of course, we can't +>>> exclude foot-shooting here: if an admin misconfigures the plugin, +>>> they can introduce new attack vectors. But default and sample +>>> configurations should be secure. +>>> +>>> It is with that model in mind that I wrote the bibtex2html plugin: it doesn't +>>> use the shell to execute bibtex2html: +>>> +>>> [[!format perl """my @bibtex_cmd = (qw[bibtex2html -noheader -nofooter -nobibsource -nodoc -q -o -], $near); open(PIPE, "-|", @bibtex_cmd) || error "can't open pipe to @bibtex_cmd: $!";"""]] +>>> +>>> I specifically tried to address that case, to make sure users +>>> can't execute arbitrary code even if the plugin is enabled. +>>> +>>> Still: it is tricky! The above pipeline could *still* be +>>> vulnerable to certain attacks if bibtex2html does some dangerous +>>> stuff on its own. For example, it could call other executables +>>> with the shell without checking arguments, and then the filename +>>> would be expanded into hostile shell commands. Even worse and +>>> trickier, the filename could be something like `-oclobberfile` and +>>> one file would be destroyed! +>>> +>>> bibtex2html is probably vulnerable to such an attack right now. We +>>> should check attachments for weird filenames and restrict what is +>>> allowed to upload and pass to the plugin. +>>> +>>> In case you haven't reviewed the [[compile]] plugin in detail, +>>> what struck me as an interesting model is the way it allows admin +>>> to configure extensions to pipeline mappings. What I had in mind +>>> was something like this: +>>> +>>> exec_pipelines: +>>> - bib: 'bibtex2html -o- %s' +>>> - svg: 'inkscape -o- %s' +>>> - tex: +>>> - 'pdflatex %s' +>>> - 'bibtex %s' +>>> - 'pdflatex %s' +>>> - 'pdflatex %s' +>>> +>>> (forgive my YAML cluelessness, the idea above is to define a hash +>>> of extension -> (command) mapping.) The command would be broken up +>>> on spaces into an array and the `%s` element would be replaced by +>>> the source file, which would be forbidden to use shell +>>> metacharacters, including prefixed dashes. I believe such a plugin +>>> could be crafted to be secure with proper configuration +>>> +>>> Of course, it's better if there's a native plugin for +>>> everything. For bibtex, we need to use Text::Bibtex, for +>>> example. But that basically means rewriting bibtex2html in Perl, +>>> which not something any user can do easily. And it's an even worse +>>> problems for documents like Word spreadsheets or Latex +>>> documents. Only the native commands can do the right thing. +>>> +>>> A clever admin can certainly find out about such a command and +>>> having a way for that admin to easily hook that into ikiwiki would +>>> be a powerful tool, with all that implies. --[[anarcat]] + +>>>> Concerning the ability to run arbitrary commands, a [[discussion was +>>>> started|https://ikiwiki.info/plugins/contrib/compile/discussion/]] by someone +>>>> who wanted a secure version of this plugin. The idea I had (which has some +>>>> similarities with what is being discussed here) was to provide a +>>>> `compile_secure` boolean option to restrict what the user can do (if +>>>> false, users can run arbitrary commands; if true, users can only run a set of +>>>> predefined commands). However, since [[fr33domlover]], who started the +>>>> discussion, did not answer, nothing was implemented. +>>>> +>>>> Concerning arbitrary commands, I do not know Perl, but I think it can run +>>>> commands using something similar to [exec](http://linux.die.net/man/3/exec), +>>>> which prevents (?) shell injections. This adds the burden of manipulating +>>>> arrays instead of strings, but security should be improved. +>>>> +>>>> But none of those ideas solve the problems you mentionned, being that +>>>> external commands can do nasty things (the `-oclobberfile` option of +>>>> `bibtex2html`) or contain bugs (like ImageMagick). +>>>> +>>>> If we want to merge this plugin and compile, I think a better idea than the one +>>>> I proposed at the beginning of the discussion would be to provide two different +>>>> directives: a `\[[!compile "foo.bar"]]` would compile the file and render it as a +>>>> link to the compiled file (what the compile plugin does right now), while +>>>> `\[[!render "foo.bar"]]` would compile the file, +>>>> and render its content in the current page (whath the bibtex2html plugin +>>>> does). In fact, providing this +>>>> `\[[!render ...]]` directive (without the security considerations) seems +>>>> easy enough to implement, and I might implement it some day (soon, if it +>>>> solves [[anarcat]] problem and closes the discussion). +>>>> +>>>> While I am really happy to see that my plugin sparks some interest, I fear I +>>>> won't be able to implement what is discussed here, apart from the quick +>>>> feature I mentionned in the previous paragraph (I have a baby at home, I am +>>>> moving to another city in a few weeks, and the only code I ever wrote in Perl +>>>> was to contribute to IkiWiki). However, you have my blessing for making +>>>> whatever you want with my code: contribute, write a version 2 of it, write a +>>>> new plugin that makes it obsolete, copy the good ideas and dump the rest, etc. +>>>> +>>>> --[[Louis|spalax]]