Detecting harmful LaTeX code

Question

I'm writing a website which allows users to enter some text in predefined text fields. This text gets passed on the server where a LaTeX document is created (containing the text entered by the user). The server finally returns a compiled LaTeX document (a pdf) to the user. Note: the user doesn't enter the whole tex document, only parts.

My problem: how can I make sure that the entered text will not harm my server? I.e. how to detect harmful LaTeX code?

Some examples:

The user entered an infinite loop written in LaTeX, the server can't compile the document.
The user entered a shell script which will be executed from the tex file when compiling, potentially crashing my server.

Is my best alternative to blacklist any LaTeX code? Is detecting \ followed by a non-space enough to block any potentially harmful LaTeX code?

I've written an answer covering what I believe to be the basics, but you should probably look into what sharelatex and overleaf permit (I have a feeling I've seen some details online but that was some time ago and I can't find it now) — Chris H, Oct 20 '16 at 11:25
Disable all shell-escape (including the restricted ones) and run LuaTeX with the --safer option (or don't use it at all). Of course, never run TeX as root. — Henri Menke, Oct 20 '16 at 11:30
@BrunoLeFloch depending on the document you might need to whitelist \begin{figure} (or tabular or equation etc.) even if \begin{document} is provided by the template. Perhaps the OP should expand a little on what user input will consist of. — Chris H, Oct 20 '16 at 12:53
Another option if you need only very basic formatting commands etc: don't accept TeX input. Accept markdown and pass through pandoc to convert to LaTeX, trimming any extraneous material (preamble). — Chris H, Oct 20 '16 at 12:58
@BrunoLeFloch To be clear: that won't reveal any passwords. It would, however, provide a list a user names. But if the security of the system depends on users not reading a file marked world-readable, there's a problem. On a secure system, this cannot be a real threat. Users can cat /etc/passwd on multi-user systems, but that doesn't really compromise the system. In theory, knowing user names makes an attack slightly easier, but strong passwords and standard precautions mean that makes little difference. The attacker already knows there's a root user, for example. — cfr, Oct 20 '16 at 14:59
@cfr Once you know the username (or guess it from /etc/passwd), you can read user's sensitive data, e.g.: \begin{input}{/home/guessed-username/.netrc}. This is a serious threat! — yo', Oct 20 '16 at 19:54
Great, now we need a Anti-LaTeX-Malware program written in LaTeX as well... — Tobias Kienzler, Oct 20 '16 at 19:59
Are the text fields simple text fields without any LaTeX markup? Or should a subset of LaTeX be supported? — Heiko Oberdiek, Oct 20 '16 at 20:20
@yo' If other users can read sensitive data in my home directory, the system is not secure. Any user can do ls /home to get the names of other users. There is no threat here at all unless the system is already insecure because the permissions on directories are inappropriate. For me to read your .netrc, your home directory must be world readable and world executable (or I must be in the same group as you and it must be group readable and executable) and .netrc must be world readable (or group readable). If that is true, my reading /etc/passwd is beside the point. — cfr, Oct 20 '16 at 21:28
@cfr but this way someone can propagate your .netrc into a PDF document they are allowed to open. — yo', Oct 20 '16 at 21:30
@yo' No they cannot. You can't do that unless you can read it. You shouldn't be able to read it. There is no threat here. /etc/passwd is world readable. It is assumed that everyone can read it. That is simply not a threat at all. Knowing your username does not give me access to your files unless the system is fundamentally insecure. If that's the case, you have more to worry about than my reading /etc/passwd. Knowing your user name doesn't give me access to anything. There is no threat here. It is just FUD. — cfr, Oct 20 '16 at 21:33
@yo' Unless, of course, you are compiling as root. But obviously nobody sensible would ever do that. — cfr, Oct 20 '16 at 21:36
@cfr But there is no "you" in the problem. The user that runs the script is the user that created the script, if I understand things correctly. The person that inputs the data is someone else. Or do I miss something? — yo', Oct 20 '16 at 21:37
@yo' No. You would not run the compiler as a user with a home containing sensitive data. You don't run anything which is publicly available as a normal user at all. If you are doing that, then malicious LaTeX is the least of your worries. — cfr, Oct 20 '16 at 21:51
@yo' Probably the effective user's home directory is /dev/null or /srv/http or something along those lines. I've never done this so I don't know the details, but if you are bob, say, you don't run anything on the public side as bob. — cfr, Oct 20 '16 at 21:54
You probably want to look into the sandboxing techniques that online C compiler sites use to protect themselves. (Especially the ones that let you compile & run your code on their server.) — Peter Cordes, Oct 21 '16 at 08:16
@cfr is right. As long as TeX is run by a user with sufficiently few read permissions the system can be kept secure. — Bruno Le Floch, Oct 21 '16 at 16:06

David Carlisle · Accepted Answer · 2016-10-20T20:14:11.797

web2c based tex's have quite a lot of customisation to control this. As is a well known theorem of Turing, it's not possible to detect all possible infinite loops in any non trivial programming language, so if the tex code is \def\x{\x}\x it will loop forever, however any web hosting setup should allow you to specify time limits for any forked processes so that isn't really a problem, you can always kill the job after whatever time limit you want to set.

running scripts is not allowed by default so your second concern is only an issue if you allow it to run arbitrary user specified commands, so don't do that:-)

You may also want to clamp down on the ability to read files outside of the input tree by banning reading of /etc/passwd etc (writing such files is again prevented by default)

the texmf.cnf controlling your text installation will have

% Do we allow TeX \input or \openin (openin_any), or \openout
% (openout_any) on filenames starting with `.' (e.g., .rhosts) or
% outside the current tree (e.g., /etc/passwd)?
% a (any)        : any file can be opened.
% r (restricted) : disallow opening dot files
% p (paranoid)   : as `r' and disallow going to parent directories, and
%                  restrict absolute paths to be under $TEXMFOUTPUT.
openin_any = a
openout_any = p

you may want to make openin_any also p

Other than that tex is as safe as anything else you can do, it can not spawn any new commands, it can not write anywhere other than the directory it is started from (and subdirectories of that) and it can not read any files out of the specified input path.

\endinput% this file is anti-social if this line is removed
\makeatletter
\ProvidesFile{xxx}[\noexpand\ver@xxx]
\ProvidesFile{xxx}[\ver@xxx]
\documentclass{article}


\begin{document}

\end{document}

Why openin_any = a? Doesn't that allow to read /etc/passwd? — Bruno Le Floch, Oct 20 '16 at 12:50
@BrunoLeFloch it is what it is (yes, if you have read permission for that) — David Carlisle, Oct 20 '16 at 12:58
@BrunoLeFloch So what? What does reading /etc/passwd get you exactly? — cfr, Oct 20 '16 at 15:02
That is a mis-characterization of the halting problem. (As you probably know). It is not possible for a program to detect all "infiniteloops", but it is very possibly for a program to detect many infinite loops. Though in this case, I guess it doesn't make much different — Frames Catherine White, Oct 20 '16 at 20:10
@Oxinabox er yes it's what I meant of course, it is definitely possible to detect some loops, there is one in the code at the end of the answer for example:-) I'll re-word a bit. — David Carlisle, Oct 20 '16 at 20:13

Chris H · Answer 2 · 2016-10-20T13:02:07.120

14

Detecting anything starting with a backslash is probably going too far. WIthout knowing the content of your documents, \emph{}, \textsuperscript{}, $\mu$m may all be reasonable.

You should certainly disable shell-escape to prevent arbitrary command being run.

You should probably run the compiler in a sandbox of some kind (heavily dependent on your host system so I couldn't give details even if I was an expert). You can also have a watchdog to kill the process if it runs unreasonably long (it sounds like you have a good idea of the job structure and could predict the runtime). Setting text is quick so an abnormally large input shouldnt increase the time by much.

Most attempts to hang a LaTeX compiler would be more likely to cause it to abort -- possible with a "TeX capacity exceeded" error. But of course it might take some time to do that. So a reasonable code-validating step might be to check for and block \def, \newcommand and equivalents. It would annoy some users (like many people here) but would make it a little harder to (deliberately or otherwise) hang the compiler by things like uncontrolled recursion. There are ways round this using \begin{def} so it would probably be a good idea to whitelist any environments that we can \begin.

edited Oct 20 '16 at 13:02

answered Oct 20 '16 at 11:22

Chris H

8,705

1

\begin{def}\x{a\par\x}\x gives an infinite document (each paragraph consists of a single a). – Bruno Le Floch Oct 20 '16 at 12:48
@BrunoLeFloch, sneaky use of \begin to avoid \def is quite clever. A watchdog/process time limit should kill the process eventually but limiting what you can \begin is starting to look like a good idea (my comment to your comment under the Q). I'll add something. – Chris H Oct 20 '16 at 13:00
4

@ChrisH trying to parse the file to spot bad commands is entirely pointless, anyone trying to put bad stuff can hide it, how would you parse the valid tex file found at https://www.ctan.org/pkg/xii to work out what it is doing? – David Carlisle Oct 20 '16 at 13:18
@DavidCarlisle not entirely pointless. Proper sandboxing, disabling scripts, limiting process time and permissions are your main lines of defence (as you've expressed more clearly and in more detail than I could have done). But you could reduce the load on your server blocking by certain commands which could easily be used to cause problems. Your xii.tex prompts another idea: setting another char to catcode 0 to get round previous filtering ideas. A whitelist would be better than a blacklist, but would be huge if things like amssymb are available. – Chris H Oct 20 '16 at 13:28
@ChrisH I added a different example to my answer... – David Carlisle Oct 20 '16 at 13:38
@DavidCarlisle hence why a whitelist would be better than a blacklist - \ProvidesFile shouldn't be on it (not needed in a document file). Without any of the commands to create macros, you shouldn't need \makeatletter or \noexpand (true whether you use a whitelist or a blacklist). Anyway, your answer gets my vote but I think mine adds something. And I'm in no doubt that someone like you could get round any input controls the rest of us could come up with (even my Pandoc comment probably has holes). – Chris H Oct 20 '16 at 13:46

Detecting harmful LaTeX code

2 Answers2