[tex-live] epstopdf.sty 2008 vs 2009

[Manuel Pégourié-Gonnard]

Heiko Oberdiek a écrit :
> That is in fact quite unrestricted with the current list of
> allowed programs. The list has improved, but there are still
> too many security holes:
> 
> % running through etex, latex, pdflatex, ...
> \immediate\write18{ls -l}% disallowed
> \immediate\write18\expandafter{\detokenize{%
>   etex -shell-escape \immediate\write18{ls -l}\end
> }}% but this is allowed
> \csname @@end\endcsname\end
> 
I agree, we should not leave this obvious one open.

> If theses programs should be part of the list, then
> the code that checks the program call could add a check
> for (Perl pattern):
>   \w--?shell-e
> * Options can start with one or two hyphens.
> * Options can be abbreviated. Because of "-shell-restricted"
>   the shortest variant is "-shell-e".
> * -no-shell-escape is ok.
> 
I wonder what the best approach is. Hard-coding this in the C code doesn't sound
good to me (I wonder if it is what you had in mind). Moreover, it's probably not
a good time to change sources of binaries since the final build was called for a
few days ago.

I was think of using a small Perl wrapper called rtex for restricted TeX, which
would do the necessary checks and launch the engine. We could either create
symlinks rpdftex, etc to it of make it use a syntaxe like

rtex pdftex -options file

The drawback (with both approaches btw) is that it requires changes at the macro
level. However, I cannot imagine better solution at this point.

> a) The executed programs must be known. It should be impossible
>    for an attacker to write a program/script/batch file with
>    a allowed name and call it afterwards. Main problem is
>    the current directory in PATH (not recommended anyway, but who
>    knows). The position doesn't matter. If the current directory
>    is the last one, then the attacker can still use names of
>    programs that aren't installed.

I was about to answer that the use/admin is responsible for what is in its path
and executable, and not having . in its path since it is a very well-known
security flaw. But then I thought of windows. I think that having . in the oath
is the custom there. Moreover, there is not the protection that the executable
must be set (which cannot be done from TeX). Whouch.

> b) Arbitrary command calls must not be allowed. That requires
>    that each program that wants to be added to the allowed list
>    must be checked/audited/discussed, whether this is possible.

Except for the various TeX engines, are their other programs in the list likely
to allow execution of arbitrary commands in any way to the best of your knowledge?

> c) Writing files: Except for TeX programs external programs
>    don't know about `openout_any' or `openin_any'. Thus they
>    are able to write their results in any place that the
>    operating system permits. This is the price of restricted
>    mode. At least it should be impossible to write arbitrary
>    files. Settings of openout_any or openout_in aren't
>    necessarily inherited. Care is necessary, e.g.
>    texmf.cnf allows "openout_any=a", but `etex' is called
>    with environment variable "openout_any.etex=p", but the
>    called program is `pdfluatex' ...
> 
I think we should just accept and document that. I can't see any realistic way
to circumvent it.

Manuel.