When using the \includegraphics command from the graphicx package, are there any security implications when using images from someone whom you don't trust, who may potentially be an adversary?

If you're now wondering why anybody would do that, I don't think this scenario is that far-fetched at all. I'd just like to be sure that, although I may take some images that I received via email and include them in my LaTeX documents, my computer is not in immediate danger of being hacked.

Of course, I know that there's never 100% security, but this question is about what is likely to happen, or not to happen.

Other pieces of software that process images, such as ImageMagick, have had some serious vulnerabilities from time to time. So I'm wondering if that's possible (or rather, likely) with LaTeX (XeLaTeX) as well.

If the images are just copied into the resulting PDF as they are, bit by bit, the risk is probably low. But if the images are processed in some way, e.g. when using the width, height, scale or angle options, the risk is probably much higher.

Edit: Generating two PDFs via XeLaTeX, one with a PNG image included and one without, I could see that 123.6% of the PNG file's size is added to the PDF file's size. So the bytes of the PNG are definitely not just written into the PDF as they are, however that might have worked.

Reading how images inside of PDF documents actually work [1] [2] [3] and trying to understand a tiny bit of what graphicx does [4], it seems that image data is at least decoded and then re-encoded for use in PDFs. So that's what LaTeX probably does. That would mean there's definitely a minor attack surface where vulnerabilities might occur, since LaTeX does not just forward the bytes from the image but touches and processes them.

On the other hand, it seems that altering the dimensions or rotating an image does not involve any real processing, but just some slightly different controls written to the PDF that change how the viewer later displays the image. I can support this assumption now after testing different combinations of the width, height and keepaspectratio options, all producing PDF files that vary in their file sizes by just 0 to 2 bytes, although the PNG file inserted is about 13 KB.

  • this can be stretched to any form of content used in LaTeX as discussed in this paper: cseweb.ucsd.edu/~hovav/dist/tex-login.pdf hence, while this is a valid question regarding the security features of LaTeX, I think the topic itself is too broad. – naphaneal Mar 15 '17 at 17:27
  • 1
    @naphaneal Thanks! I had read that paper a while ago already, and I don't think it's related in any way, actually. This is about LaTeX source files which you should not compile without looking at them, obviously. Some could put some commands in them that executes or includes things you don't want. But in my situation, I don't allow any arbitrary commands to be entered. The only thing I "allow" is images (JPEG, PNG, (PDF)) that I have not thoroughly checked. This is a completely different matter, I'd say. But as written in the question, I don't know what graphicx does under the hood. – caw Mar 15 '17 at 19:12
  • 1
    Maybe you should have a look here security.stackexchange.com/questions/8113. In addition, you can open the picture file in a text editor like notepad++ and see if there is additional stuff. – Dr. Manuel Kuehner Mar 15 '17 at 22:30
  • @Dr.ManuelKuehner Thanks! Opening images in a text/hex editor might not be that helpful due to the long sections of binary data that one cannot interpret without deeper knowledge on the specific format. On the other hand, if somebody had just renamed an .exe or .sh file to .jpg, one could probably catch it this way. But knowing that those executables wouldn't pose a risk, anyway, would be even better, of course. The question that you linked to is more about risks for people viewing documents later (e.g. due to embedded scripts), less about risks for the person compiling them. – caw Mar 16 '17 at 19:38
  • Ok :). I wanted to give it a shot, since the question did not get a lot of attention. – Dr. Manuel Kuehner Mar 16 '17 at 19:50

The latex \includegraphics macro itself doesn't do anything that couldn't be done without it (it's just a tex macro not using any special instructions that could not be used directly).

This means that in particular a document that does not use the graphics package has exactly the same security issues as one that does.

\includegraphics itself does very little it just offers a consistent interface to specifying the filename and size etc. and then asks the "back end" to arrange to include the file. The "back end" here might be part of the same program for systems like pdftex or luatex, or a separate dvi driver program for latex+dvips or xetex+xdvipdfmx etc.

In earlier, more trusting, times the file image conversion calls could run essentially anything. dvips for example has a convention that if you prefix the image filename in the \special that specifies image inclusion with ` then it calls out to the shell to execute a conversion command, so for example `zcat foo.eps.Z would uncompress a compressed eps file and stream the resulting EPS into dvips' image handler. Originally the graphics package had this as the default setup for .eps.Z file extensions but similar rules could be used to invoke anything by sending some bactick string to dvips.

For some years (decades probably) dvips is by default configured not to allow this and instead has some special detection of compressed images that don't involve specifying any external command, and shell escape mechanism via backtick is turned off by default.

Similarly pdflatex can not natively include eps so uses epstopdf (a thin wrapper around ghostscript) to convert EPS to PDF. Again for many years you have not needed to use an explicit --shell-escape to pdflatex to enable this (and so risk enabling other shell commands being invoked) but instead a restricted repstopdf script is whitelisted and allowed to run in the default "restricted" mode. This runs ghostscript in its SAFER mode and has almost all options and non-local file access disabled so it is highly unlikely that it can be used for anything other then convert an eps to pdf in the current directory.

The set of commands whitelisted and allowed to be called by tex without an explicit --shell-escape argument is very small but also user-setable in texmf.cnf The default list is

% The programs listed here are as safe as any we know: they either do
% not write any output files, respect openout_any, or have hard-coded
% restrictions similar to or higher than openout_any=p.  They also have
% no features to invoke arbitrary other programs, and no known
% exploitable bugs.  All to the best of our knowledge.  They also have
% practical use for being called from TeX.
shell_escape_commands = \

% we'd like to allow:
% dvips - but external commands can be executed, need at least -R1.
% epspdf, ps2pdf, pstopdf - need to respect openout_any,
%   and gs -dSAFER must be used and check for shell injection with filenames.
% pygmentize - but is the filter feature insecure?
% ps4pdf - but it calls an unrestricted latex.
% rpdfcrop - maybe ok, but let's get experience with repstopdf first.
% texindy,xindy - but is the module feature insecure?
% ulqda - but requires optional SHA1.pm, so why bother.
% tex, latex, etc. - need to forbid --shell-escape, and inherit openout_any.

So basically this isn't a full security review, but as far as we are aware, graphics inclusion doesn't impose any risks that are not present in running any other tex document.

If you are in an insecure environment you could and perhaps should use tex with --no-shell-escape which will prevent even the whitelisted programs running, that would have the effect that (for example) pdflatex would not be able to include eps file automatically but you would have to arrange to convert the eps to pdf in advance in whatever way you consider to be a secure.

  • Thank you very much! I didn’t know that the \includegraphics macro doesn’t do much itself. So my question should probably have been about the implications of including graphics in TeX in general. That may be a bit too broad, but what I was mainly concerned about was how image data is handled or processed, e.g. for an inclusion “as-is”, with resizing, rotations, etc. Are images decoded and re-encoded? Or are their bytes just included as they are and an annotation tells the PDF viewer to resize or rotate it? ImageMagick had 30 known vulnerabilities in 2018 alone. – caw Oct 5 '18 at 13:26
  • 1
    @caw but that is a different answer for each back end (pdftex, luatex,dvips, xetex/xdvipdfmx,...) and actually I don't know the answer to any of them, at the latex side of things that's rather the point it just says include here... so even though I wrote includegraphics I don't typically even need to know what filetypes each system can include. scaling and rotation though are typically handled by includegraphics wrapping in pdf transform calls, just as if you had \rotatebox around it so the rotation is just a pdf coordinate transform separate to the image inclusion, ... – David Carlisle Oct 5 '18 at 13:33
  • @caw .. however some bitmap formats for some back ends you can specify the scale straight to the backend so it can (hopefully) sample the bitmap rather than sale. – David Carlisle Oct 5 '18 at 13:33
  • So if the graphicx package, or rather TeX itself, as I’ve learned, does image processing (like ImageMagick), and both are written in similarly “unsafe” languages (e.g. WEB/C), where memory corruption, out-of-bounds writes/reads, denial of service, etc. can happen through crafted files of standard types such as JPEG/PNG, TeX could have a lot of undiscovered vulnerabilities as well. That would make sense since TeX was not designed with attackers and hostile/untrusted input in mind. But you may want to compile someone else’s paper or just include graphics found on the internet, right? – caw Oct 5 '18 at 13:40
  • 1
    @caw traditionally tex doesn't even touch the image file, classically it would just write a \special with the filename, what happens after taht depends on what you do with the dvi file, dvips or xdvi or whatever. pdftex (and now luatex) change that a bit by basically incorporating back end inclusion code into the same executable. which affects your question but not the way the latex macros are written as the fact that pdftex's pdf writing is part of the same executable is essentially not visible from within tex. – David Carlisle Oct 5 '18 at 13:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.