Take the 2-minute tour ×

TH. writes, in How should one use \write18 with BibTeX:

Now that TeX Live 2010 has a restricted \write18, I figured it'd be reasonable to update my cv which uses the bibunits package to run BibTeX for each of the .aux files.

I'm aware of a history of discussion about using limited priorities to sandbox Tex execution, but I hadn't seen anything saying that the difficulties doing this had been solved. Is there anything like a report, ideally something along the lines of a security audit, that gives a threat model and discussion of Texlive's ability to deal with it?


Just to be clear, this question is about understanding what risks the use of Texlive 2010 places its users at.

The main thing I'm worried about —but the question is not limited to this— is a risk comprehension issue: it's easy to grasp that with '\write18' accessing the full privilege user shell, you are letting your Tex manuscript to do anything to your machine that you can do (hopefully, that is, without admin privileges). With restricted shell, the risk is more subtle: the restricted shell can only run permitted executables, which sounds safe, but a cleverly constructed Tex style file might be able to exploit a bug a "safe" executable so your machine joins the Storm botnet. The value of a security review is that it makes the risk clear, and anything like one is a good thing.

share|improve this question
There was some analysis for the approach they tried to take in 2009, and which was abandoned due to some pretty serious issues. I've not seen a similar take on the current approach, but for the really paranoid there is a setting to turn it off entirely. –  Joseph Wright Oct 26 '10 at 13:03
@Joseph: with a link to that analysis, your comment would make a valuable, if incomplete answer. –  Charles Stewart Oct 26 '10 at 13:20
Looking back, it seems I was thinking of MiKTeX: cseweb.ucsd.edu/~hovav/papers/csr10.html –  Joseph Wright Oct 26 '10 at 14:02
@Joseph: That is a very good link. It's not explicitly about Texlive, because its proof-of-concept involves Windows, but it provides an excellent survey of attack vectors, and a useful discussion of methods to combat them. It doesn't have a threat model (who wants things to happen to the user's machine that the user doesn't want), which is something that a security report really should start with. –  Charles Stewart Oct 27 '10 at 8:17

3 Answers 3

up vote 10 down vote accepted

I first started commenting on Will's and Joseph's comments and answers, but my reply may be too long for a comment. So, first of all, concerning the withdrawal of restricted \write18 in TL2009, if I remember correctly there was mainly three reasons:

  1. There was specific issues on Windows, mainly related to the fact that Windows picks binaries from the current directory first (even if . is not in the PATH variable). Combined with TeX ability to write arbitrary files in the current directory, this was a huge threat. The approach taken now is (a) forbid writing files with "executable extensions": exe, com, etc. (taken from the standard environment variable PATHEXT if set at runtime, or from a built-in list otherwise); (b) invoke executables with full path whenever possible.

  2. As you rightly point out, the system is as weak as the weakest allowed executable. There's two things we want from an allowed executable: (a) don't allow execution of arbitrary commands and (b) respect TeX file I/O restrictions as implemented in TeX Live. Many executables in the initial default list (most notably bibtex and makeindex) didn't satisfy (b), now they do. More importantly, the script epstopdf (which was the primary motivation for restricted write18) didn't, and at some point was prone to shell injection (hence arbitrary command execution). Now we believe epstopdf is robust in this respect (more precisely, its newly-created restricted version repstopdf is).

  3. A implementation mistake (more a typo than a design issue btw) was discovered lately on Unix, which allowed shell injection directly from TeX. While we could have fixed it immediately (hence delaying the release further for rebuild), at this point we really felt like the feature was not ready for prime-time and required more relaxed (as opposed to rushing for release) thinking and careful proofreading.

To sum up, the current approach is not new, it's basically the same as planned for 2009, only a lot of "details" have been fixed, but the devil is in the details. Beside the "historic" interest, I hope this explanation sheds some light on which issues were considered.

Now, security is not only about executing commands, it's also about file I/O. The "texhack" paper cited by Joseph deals only with writing or reading files, which is nothing new (but not completely unrelated to restricted \write18 either, see points 1 & 2b above). Basically, file reading may lead to information leak in some contexts (tex as a web service), while file writing may lead to data loss or arbitrary command execution. As pointed out in the paper, TeX Live provides some protection. By default, only file output is restricted to the current directory or TEXMFOUTPUT if set, (and writing dot-files on Unix and files with "executable extensions" on Windows are forbidden), but file input can easily be restricted in the same way. It is very important to notice that this protection is efficient only if you process untrusted files in a "safe" directory (a temporary one for each document), as opposed to your home.

Concerning documentation, a section was added in the TeX Live guide (section 1.4). It doesn't discuss the subject extensively, but at least sums up the mains issues and the precautions a user can take.

share|improve this answer
OK, good. The issue isn't really closed until conscientious non-experts can quickly grasp what sort of risks there are from the documentation, and I don't agree that section 1.4 does a good job, but this post, I think, contains enough information to be crafted into something that does. I'll accept this: it looks pretty complete. –  Charles Stewart Oct 28 '10 at 13:29
FWIW, I didn't mean that section 1.4 does a good enough job, just point out that it exists (which is still better than nothing). –  mpg Oct 28 '10 at 14:00

Just for a little history: restricted shell escape has existed since TeX Live 2009. It was decided to be inactive by default then due to security concerns.

If memory serves, here's where the problems started being discussed before the feature was dropped from being "on by default" in TeX Live 2009: http://tug.org/mailman/htdig/tex-live/2009-July/021574.html

And here's the end of a (rather long) thread in which, eventually, the feature was announced as withdrawn: http://tug.org/mailman/htdig/tex-live/2009-October/023430.html Few details were given on the exact decisions made leading up to this.

But I don't follow the TeX Live mailing list most of the time so I'm not sure if or when the new-and-improved implementation (active by default) was discussed there for TeX Live 2010.

share|improve this answer
Not sharing the concerns they discussed in nearly a year? Doesn't exactly sound like full disclosure, does it? I hope there is a nice, complete, clarifying email that you overlooked, but I'm guessing that if there was, you would have heard of it. –  Charles Stewart Oct 27 '10 at 8:45
My understanding is that getting the security right was just harder than they thought—seemed to me that the feature was dropped in TL2009 because it wasn't ready yet security-wise, not because it was inherently insecure. But I'm not an expert: perhaps asking on the TeX Live mailing list would give better results. –  Will Robertson Oct 27 '10 at 21:52

I know this isn't an answer to the question, but perhaps could help you with your problem. PerlTeX allows you to embed Perl code as a LaTeX function. When compiling if you use perltex --nosafe myfile.tex then the perl process has free reign to call system functions. I'm not sure if this could help your problem (because of an order of operations, though if \write18 would work at compile time then this should), but it is a way to get full access to your system as well as other benefits of using inline Perl code in your source.

share|improve this answer
How does this help? This only makes things worse. –  TH. Oct 27 '10 at 3:07
I've written a postscript to the question to clarify that this isn't my problem. Lack of knowledge of how to use Tex to compromise my system's security isn't it... @TH.: Note that Perl does have some nice support for limiting the damage Perl code can do. Perl CGI is the only form of dynamic web content I trust/allow on my website. –  Charles Stewart Oct 27 '10 at 8:34
Oops, sorry, misunderstood. I just thought you needed a way to execute some system command. Gotcha now. Talk amongst yourselves ... [moves towards the door] –  Joel Berger Oct 27 '10 at 14:23

Your Answer


