[tex-live] Status of restricted \write18 and epstopdf conversion
mpg at elzevir.fr
Mon Oct 19 12:17:21 CEST 2009
Alexander Cherepanov a écrit :
> 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, except TL09 which is
still in testing phase. MikTeX makes everything differently: different
TeX implementation, different esptopf executable...
(That doesn't mean it's not worth checking if MikTeX is subject to some
of the problems we discussed here, but a priori their problems are not
the same as ours.)
> I also didn't waste time today, here is the next part of the problems;)
Thanks ! -- but sigh, too :-)
> 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).
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.
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
> 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. :-)
> 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
I'll look into the windows stuff later.
Thanks a lot for all your remarks,
More information about the tex-live