[tex-live] Status of restricted \write18 and epstopdf conversion

[Alexander Cherepanov]

Hi Manuel!
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
>> else?

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

Right.

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

  open(OUT,">$OutputFilename")

to

  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.

Cool.

> (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.
> Right?

Yes, sorry, I should have mentioned it.

> I'll look into the windows stuff later.

Alexander Cherepanov