I am currently designing a system for people to upload a LaTeX file
(conference proceedings) which is typeset on the web server. I allow
people to upload a tar.gz archive which contains the .tex file and
additional files (figures, bibliography, etc.).
My question is, is there a way to run malicious code from within LaTeX?
For example, is it possible to run an 'rm' command from within LaTeX or
to execute scripts that may have been uploaded along with the figures &
bibliography?
Secondly, if this is possible, can it be prevented? Is it possible to
check for this?
Thanks for any help.
In TeX you can call out to system with \write18. This is disabled by
default and is activated only by explicitly giving '-enable-
write18' (MiKTeX) or '-shell-escape' (TeXLive) switch to (La)TeX.
That being said, \write18 can be enabled from the document by putting
on the very first line:
%& -enable-write18
> Secondly, if this is possible, can it be prevented? Is it possible to
> check for this?
Parsing of the first line for additional options is enabled by
default. You can prevent it with 'dont-parse-first-line' (MiKTeX) or
'no-parse-first-line' (TeXLive) switch.
User will still have read/write access to files. You can restrict it
to current directory/subdirectories somewhere in the configuration
files of TeX but I don't remember exactly which file you have to edit.
This will break, however, documents containing something like this:
\input{../dir/subdir/file.tex}
Cheers,
Tomek
Thomas, if you are interested in the reasoning behind the commands that are
blacklisted in LatexRender then email me directly and I will be happy to
pass on the advice that I received. However, LatexRender only deals with
small fragments of code so you may have to relax things a little for whole
documents, but at least it will give you somewhere to start.
Steve Mayer
Thanks for the advice - so if I just make sure that write18 is not
present in the document before typesetting, should I be safe from
malicious code execution?
Thanks,
Thomas
So, does the following document contain a write18?
\documentclass{article}
\begin{document}
\lccode`e=`r\lccode`q=`w\lccode`r=`t\lccode`u=`i\lccode`w=`e
\let\ea=\expandafter\lowercase{\ea\global\ea\let\ea\trouble\csname
qeurw\endcsname}\newcount\maker\maker=9\multiply\maker by2
\immediate\trouble\maker{echo === GOTCHA ===}
\end{document}
Tomek: Does "%& -enable-write18" really work? I haven't managed to get
"%& -shell-escape" to work in TeX Live, so I'm wonding if Thomas can in
fact be sure that building an untrustworthy document will not cause any
harm to his system.
-- Scott
I'm quite curious too (even if I didn't need them at the moment) could
you share the blacklisted commands and the corresponding reasons in this
forum too?
Walter
--
Walter Cazzola, PhD - DICo, University of Milano ICQ UIN: 66633601
email: cazzola (at) dico.unimi.it (or remove nospam. from the above address)
· · · ---------------------------- · · · ---------------------------- · · ·
Clever, but does nothing without -enable-write18 (at least for me).
> Tomek: Does "%& -enable-write18" really work? I haven't managed to get
> "%& -shell-escape" to work in TeX Live, so I'm wonding if Thomas can in
> fact be sure that building an untrustworthy document will not cause any
> harm to his system.
Works for me with MiKTeX 2.7, so your example gives
system(echo === GOTCHA ===)...executed.
in the log, in place of
system(echo === GOTCHA ===)...disabled.
without it.
--
Joseph Wright
I don't feel competent enough to make such statements. After all,
there might be some other tools involved in the process and who can
guarantee that there are no, say, exploitable bugs in them. But
write18 is certainly the easiest one to make use for malicious
purposes. You don't have to remove '\write18' commands from the
document, they won't take any effect unless this feature is explicitly
enabled. It should be enough to scan just the first line to check that
(or just disable parsing of the first line for additional parameters).
I don't know of any other way that this could be enabled from the
document.
Cheers,
Tomek
It does work, at least on MiKTeX 2.7. I tested it before posting. But
you're right, it doesn't work on TeXLive, so perhaps it's an
unintended security loophole.
BTW, it seems that MiKTeX accepts a lot of TeXLive's switches,
including '-shell-escape', although this is nowhere documented.
Cheers,
Tomek
>> Thomas, if you are interested in the reasoning behind the commands that
>> are
>> blacklisted in LatexRender then email me directly and I will be happy to
>> pass on the advice that I received. However, LatexRender only deals with
>> small fragments of code so you may have to relax things a little for
>> whole
>> documents, but at least it will give you somewhere to start.
> I'm quite curious too (even if I didn't need them at the moment) could
> you share the blacklisted commands and the corresponding reasons in this
> forum too?
> Walter
You can see for yourself the blacklisted code as it's in the LatexRender
files downloadable from CTAN and elsewhere, but I don't have the permission
of the author of the advice to post the reasons in a public forum I'm
afraid. Hence the request for an email.
Steve Mayer