31

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.

Improve this question
23
  • 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, 2016 at 15:10
  • 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, 2016 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, 2016 at 1:11
  • 10
    Bad Mallory, bad, bad Mallory!
    – Paulo Cereda
    Apr 22, 2016 at 15:58
  • 11
    By the way, it happened: tug.org/pipermail/tex-live/2016-June/038793.html
    – egreg
    Dec 27, 2016 at 21:42

1 Answer 1

Reset to default
6

No, CTAN is not secure against attackers uploading bugged versions of well-known packages.

The only way to prevent any hypothetical attack would be to require the uploaded packages to be signed by the author.

Improve this answer
4
  • 2
    But there is a way more trivial attack than injecting the servers. The package manager tlmgr fetches updates via unsecured HTTP, so you could just MITM the connection and override the, e.g., pdflatex binary by just telling tlmgr »Hey, there is an update for pdflatex. Please install it.«
    – Henri Menke
    Jul 17, 2017 at 5:48
  • 1
    Regarding the question discussed in the comments to the question, whether TeX could “sandbox” the macro code to prevent files from being rewritten: You are executing an application with user privileges. If you did not verify each line of the source, you just have to trust the application and its provider. Or did you read the whole source code of your webbrowser?
    – Henri Menke
    Jul 17, 2017 at 7:04
  • There's GPG authentication available
    – egreg
    Jul 17, 2017 at 8:03
  • 1
    @egreg As long as it is optional, it is as good as no authentication.
    – Henri Menke
    Jul 17, 2017 at 8:48

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.