[tex-live] Status of restricted \write18 and epstopdf conversion
cherepan at mccme.ru
Mon Oct 19 23:43:02 CEST 2009
On Mon, 19 Oct 2009 12:17:21 +0200, Manuel Pégourié-Gonnard <mpg at elzevir.fr> wrote:
>> All mentioned problems are solved. So, do you consider it a security
>> bug (shell injection in epstopdf and/or directory traverse in
>> repstopdf)? CVE, advisory and the like? Are there any distros which
>> have restricted shell-execute with allowed epstopdf? miktex2.8, what
> Currently no distro uses this restricted write18,
I hope so.
> except TL09 which is still in testing phase.
Well, every beta-tester knows that the tested program could burn
his/her computer:-) Ok, no problem here.
> MikTeX makes everything differently: different
> TeX implementation, different esptopf executable...
I'll get to this later.
>> 1. In repstopdf, you protect dot-files on unix from overwriting but
>> don't protect files in dot-directories, say .ssh/authorized_keys when
>> run from ~ .
>> Is it checked in tex when openout_any=r or openout_any=p?
> No. I did the same as TeX here, on purpose. I realised it may be a
> problem with TeX, and interestingly enough I choose the same example as
> you when writing to Karl :-)
> By the way, this particular example doesn't
> work with TeX, since it will write .ssh/authorized_keys.tex (I tried).
And here repstopdf starts to differ from tex.
BTW it's easy to bypass this restriction under windows: just add a
dot at the end of file name -- it's ignored by os but makes tex think
that there is already an extension.
> But other fils in dot-directories could be dangerous. (My example is
> ~/.vim/plugin/badhack.vim since vim can launch arbitrary commands, but
> there are probably plenty others.)
> By the way, some configuration files are not in dot-dirs. Eg,
> windowmaker puts its config in ~/GNUstep by default, and needless to say
> there a lot of potential for arbitrary commands there. Moreover, some
> people (including me) hold most of their configuration in ~/etc in order
> to manage it more easily with a version control system.
> So my conclusion is that openout_any=r is only a heuristic, and the only
> real protection is to use openout_any=p and never compile (untrusted)
> tex fils in your home, but in a "safe" subdirectory.
Then openout_any=r seems strange. It gives false sense of security.
The problem is not that it doesn't work, but rather that it makes you
think that it works while not really protecting.
> But anyway, since 'r' is sort of half of the heuristic, it would still
> be good to implement the complete heuristic at some point (both in tex
> and repstopdf).
If you cannot process untrusted .tex files in ~/ is there any sense in
keeping 'r' at all?
>> 2. repstopdf --nogs " ../file" (and ">../file") bypasses checks but
>> you have already fixed it:-)
> That's what I like with the list form of system(): it fixes things you
> didn't even think about. :-)
It's a similar but distinct issue -- note --nogs. It was fixed by
open($OUT, '>', $OutputFilename)
>> 3. repstopdf implements openout_any=p but ignores openin_any. Having
>> shell_escape=p (partially) and openin_any=p (paranoid) in texmf.cnf at
>> the same time doesn't seem very eccentric.
> Right. I'm going to implement real support for openXX_any this evening
> (must do real-life work now): most of the job is already done.
> (Obviously we can't hard-code 'p' for openin since it is too restrictive
> and is not the default.)
>> 4. In epstopdf.pl, the extension is removed from the name of input
>> file by the following line:
>> $OutputFilename =~ s/\.[^\.]*$//;
>> It should not span directory parts like in
>> ./other/sub/dir/file_wo_extension .
> Unless I'm mistaken, this is indeed a bug, but not a security flaw. The
> checks for about the file name are done after this line is executed, so
> it will not result in a "forbidden" file being written to, only "the
> wrong" file.
Yes, sorry, I should have mentioned it.
> I'll look into the windows stuff later.
More information about the tex-live