32

I was checking out how to make a CTAN package, and I was surprised that it does not involve making it account: you simply have to fill out a form. If you have a new version of a package, you simply fill out the same form again.

Now, it would be a very bad idea for me to use malicious .sty files. I tend to compile my LaTeX using a Makefile, and by default I think that .sty files are allowed to change any file in the same directory, so for instance they could change it to download and run a backdoor the next time I compile my document. Surely if the author of a package I use wants to backdoor me, they will be able to. But can random third parties update other people's packages and bug me in that way?

To be more clear, here's the attack model I'm imagining.

  1. Mallory takes the hyperref package. This package is massive, nobody will read the full source code.
  2. Mallory bugs the package. In the changelog, she claims to have solved a minor bug.
  3. Mallory waits until the authors of hyperref go on a holiday.
  4. Mallory uploads the package to CTAN under the name of the original authors. CTAN has no additional verification method and will accept the package, although they may or may not send an email to the actual authors.
  5. The actual authors will not immediately notice that an updated version has been released.
  6. Many people download and use the package from CTAN. Perhaps the bugged package even gets included into LaTeX distributions.
  7. The actual authors come back from their holiday, and find out that their package has been updated. The backdoor was sufficiently obfuscated that the authors do not see its maliciousness, and the authors blame it on someone trying to be funny.
  8. The authors roll back the package update, but do not raise a stink.
  9. Mallory does it again to a different package to infect even more people.

For added effect and morbidity, instead of hyperref, pick a package which is often used but whose author(s) have passed away. Upload under a pseudonym, and claim to have improved the package; CTAN might accept you as the new maintainer. If the package has been bugged in a skillful way, detection is very difficult.

For even more frightening effect, imagine the use of a package that frequently requires shell access (e.g., gmp).

This questions seems related but not the same: CTAN Mirror Integrity - Miktex Update . That question asks if it is possible for CTAN mirrors to be bugged; I am wondering if it is possible to actively bug CTAN itself.

Community
  • 1
Bram Geron
  • 567
  • 1
    This is really a very remote possibility, especially considering the files are text based and open source. The question itself I think is a matter of opinion. – A Feldman Apr 21 '16 at 13:31
  • To move the discussion from unverifiable tirade to something more grounded in reality, it would help if you gave some examples of which types of harm might arise from somebody "bugging", say, the hyperref package. – Mico Apr 21 '16 at 14:09
  • Bugged package tests if there is a Makefile in the directory.
  • If there is a Makefile, a line is added to the start of every target which does a number of things: (a) remove the added line again from the Makefile, (b) download a script from the internet, (c) execute the script using bash.
  • These commands are executed silently and with output piped to /dev/null so the user does not notice them.
  • The downloaded script installs malware on the computer, for instance to steal online banking information of the user.
    • – Bram Geron Apr 21 '16 at 14:19
  • @bgeron: The effort of using malware underneath TeX packages is too big and the outreach too limited, in my point of view. You're making assumptions about makefiles etc, that are not really justified. I have a makefile for my packages but I don't ship this one -- and the community is very aware about such tricks and will soon report this. –  Apr 21 '16 at 14:26
  • 9
    @bgeron CTAN check each upload in terms of file changes (added/removed) and would ask (using the email they hold) about anything 'odd' appearing (also they don't allow +x bits on any files) – Joseph Wright Apr 21 '16 at 15:10
  • 3
    Also note that with standard security settings TeX is only able to run a limited pre-defined number of processing using shell escape, and those have been checked to be safe. Unless you are allowing unrestricted shell escape a line hidden in a package can't call a script. – Joseph Wright Apr 21 '16 at 15:16
  • Thanks Joseph, you've (at least partially) answered my question in that CTAN do do manual quality control. Note that when a .sty changes a Makefile, the Makefile does not need a +x bit to be run. Also with the attack I describe, the attack is fully contained within the .sty; in particular the CTAN package would not have a Makefile itself.

    Perhaps I should make a proof of concept and a video to make the attack scenario clearer.

     – Bram Geron Apr 21 '16 at 16:32
  • 16
    I do not agree with the seemingly prevailing opinion that this question is paranoid: IMHO, the issue being made at least deserves some investigation. I am author of a package which contains a Makefile distributed on CTAN. That being said, it is also true the vast majority of users do not download packages from CTAN, but use automated update tools (like TeX Live manager) and never execute a Makefile. – GuM Apr 21 '16 at 17:59
  • 12
    I think the question is reasonable and not paranoid. I also think: things are not as bad as the question suggests; things are rather worse than most of the commentators suggest. Code in a TeX package could, theoretically, rewrite a Makefile, I think. All of the parsing etc. would need to be done in TeX, of course (unless shell escape is enabled), but that should be doable. Code could also write an arbitrary file with whatever code an have the Makefile execute it, even without the executable bit being set. – cfr Apr 22 '16 at 01:11
  • 6
    The main reason this is unlikely is because TeX users are not an especially tempting target. So long as TeX stays unpopular, it is unlikely anybody will bother. But that hardly makes for a secure system. Also, as I understand it running ConTeXt or LuaTeX is essentially to run with shell escape enabled. So anybody who uses these engines cannot count on the limited safeguards provided by restrictions on shell escape anyway. – cfr Apr 22 '16 at 01:15
  • @cfr I'm not saying there is no possibility of someone trying this, I'm saying it's very unlikely to work in practice. For a start, the most common OS in the world doesn't even recognise Makefiles out of the box (OK, one could write a batch script). You'd have to know the details of a users set up and that they are using a script to get anywhere: the vast majority of end users aren't doing that. (One might I suppose imagine a targeted attack which was aimed at one person/group.) – Joseph Wright Apr 22 '16 at 07:07
  • 1
    @cfr Note that LuaTeX's \directlua is restricted in the same way as pdfTeX: try for example \directlua{os.execute("ls -la")}\bye. This isn't true for texlua but that's explicitly for scripting! – Joseph Wright Apr 22 '16 at 07:07
  • To note that whilst this is interesting it's off-topic for us: security expertise isn't 'us' and in any case only the CTAN team can influence this area. (They were talking about having an account system but I think it was intended to be optional and that I know of hasn't happened.) I note that we've had a few questions on this general topic and it's certainly true that there are potential attack pathways but that at present they are considered sufficiently unlikely/non-useful that there is no formal review process for contributed code. – Joseph Wright Apr 22 '16 at 07:08
  • 1
    @bgeron For your suggested approach to work, you'd have to know that the user has a Makefile inside the current directory and is going to use make: as I've said, not impossible but pretty unlikely (at least in terms of the set of 'all TeX users'). You'd also have a pretty narrow 'window' before some users reported 'there is this odd file being generated' after the update. – Joseph Wright Apr 22 '16 at 07:10
  • 2
    @JosephWright: It seems you can use \IfFileExists to test if ./Makefile exists, and if so, add the malicious code on a new line after every line with a colon. – Bram Geron Apr 22 '16 at 10:16
  • 1
    @JosephWright That's good to know. That's not what I'd understood about ConTeXt, for example, from previous discussions of LuaTeX. I think the fact that people using Makefiles are likely to be more knowledgeable about what's in their working directories also makes this an unpromising line of attack. (I'm not among these people!) And anyone using version control, for example, is likely to notice the changes even if the immediate impact is non-obvious. (I'm assuming changes to other files are more frequent than Makefile edits.) But I do think we are not concerned enough about security generally. – cfr Apr 22 '16 at 12:47
  • 1
    @bgeron Yes, but I think Joseph's point was that this will only impact a small number of TeX users i.e. those on OS X or Linux or BSD or similar who use Makefiles in the first place. And then your malicious code has to be relevant to their system, which potentially narrows the possibilities down further. You almost certainly cannot touch system files, for example. You could create malicious versions of common commands, but these shouldn't ever be executed with root privileges on a properly configured system. (The widespread misuse of sudo complicates things, however.) – cfr Apr 22 '16 at 12:53
  • 2
    @cfr, you mention version control — that's another great attack vector. If you write commands to .git/hooks/post-commit, they will be executed on next commit. There are similar files that are executed after merge or checkout. Surely there are a lot of people who have .tex files in the root of their Git repository and run it from there. – Bram Geron Apr 22 '16 at 15:38
  • 1
    Comments are not for extended discussion; this conversation has been moved to chat. – Joseph Wright Apr 22 '16 at 15:41
  • 10
    Bad Mallory, bad, bad Mallory! – Paulo Cereda Apr 22 '16 at 15:58
  • 11
    By the way, it happened: http://tug.org/pipermail/tex-live/2016-June/038793.html – egreg Dec 27 '16 at 21:42
  • I found that a source forge project had a virus installed into the compiled image. I had to rebuild my pc completely. – Hannu Rouhiainen Mar 04 '17 at 17:05
  • @JosephWright LuaTeX is very insecure (or unusable): you can read or write any files (with the same permissions as the user that runs LuaTeX). With pdftex, you may write any file in the current directory : makefile, .git/config, etc. – Paul Gaborit Jul 17 '17 at 05:34