Is Arara safe/secure

Question

I have just begun playing around with arara and I am curious if there are safety/security concerns. For example, pdflatex from TeX Live has shell escape disabled by default. If the TeX Live team think that shell escape is too dangerous (and I am not sure that is the reason it has been disabled) to be enabled by default, then I am not sure it is wise to give arara so much power. Is there a way to rein in the power of arara?

One concern I have is that it might be possible to inject a malicious arara directives into a package or the aux file.

I am not so concerned about shell escape, but rather other things that can be done. For example, can an untrusted package use the file contents environment to overwrite the pdflatex rule on the first pass such that on the second pass custom code is run?

Answer 1

_{I think my answer will be totally biased, but here it goes. :)}

It's quite subjective for me to afirm that arara is safe or secure. It's just a program with a specific purpose, just like most of the tools available out there. Maybe the best answer I can come up with is: it depends.

arara per se simply expands directives into commands through rules that specify the way this expansion shoud happen. Commands are then delegated to the underlying operating system.

The program requires a valid directive (mapped to a rule) in order to run, otherwise the process stops.

Uh-oh, I could not find the 'foo' rule in the search path. Could
you take a look if the rule name is correct and if the rule is
accessible through the search path?

If there are no directives, arara will also complain.

I didn't find any directives in 'test.tex', and so didn't do
anything. Is that what you really wanted?

If we run arara with the --log option enabled, we can have a list of directives found in the .tex file.

21 Mar 2013 07:32:10.630 INFO  Arara - Welcome to arara!
21 Mar 2013 07:32:10.634 INFO  Arara - Processing file 'folheto.tex', please wait.
21 Mar 2013 07:32:10.635 INFO  DirectiveExtractor - Reading directives from folheto.tex.
21 Mar 2013 07:32:10.649 TRACE DirectiveExtractor - Directive found in line 1 with pdflatex.
21 Mar 2013 07:32:10.650 TRACE DirectiveExtractor - Directive found in line 2 with clean: { files: [ folheto.aux, folheto.log, folheto.sxc, folheto.synctex.gz ] }.
...

Heiko suggested a --dry-run option to arara, which consists of simulating the execution without actually running the commands. Hopefully it will be available in the upcoming version.

After getting the directives, arara will look for rules.

...
21 Mar 2013 07:32:10.799 INFO  TaskDeployer - Deploying tasks into commands.
21 Mar 2013 07:32:10.799 TRACE TaskDeployer - Task 'pdflatex' found in '/usr/local/texlive/2012/texmf-dist/scripts/arara/rules'.
21 Mar 2013 07:32:11.010 TRACE TaskDeployer - Task 'clean' found in '/usr/local/texlive/2012/texmf-dist/scripts/arara/rules'.
21 Mar 2013 07:32:11.083 TRACE TaskDeployer - Task 'clean' found in '/usr/local/texlive/2012/texmf-dist/scripts/arara/rules'.
21 Mar 2013 07:32:11.099 TRACE TaskDeployer - Task 'clean' found in '/usr/local/texlive/2012/texmf-dist/scripts/arara/rules'.
21 Mar 2013 07:32:11.104 TRACE TaskDeployer - Task 'clean' found in '/usr/local/texlive/2012/texmf-dist/scripts/arara/rules'.
...

arara shows the full path for the rule according to the directive. Then the commands will be executed.

...
21 Mar 2013 07:32:11.108 INFO  CommandTrigger - Ready to run commands.
21 Mar 2013 07:32:11.108 INFO  CommandTrigger - Running 'PDFLaTeX'.
21 Mar 2013 07:32:11.108 TRACE CommandTrigger - Command: pdflatex "folheto.tex"
...

Back to the question. Is it possible to run malicious code through arara? Yes. Is this a problem? No. :) After all, we can get, say, a Perl program and deliberately inject code into its execution. Or write a .tex file with malicious Lua code inside it. Or have a naughty Makefile that runs rm -rf / in our system.

I think the security issues are valid. Let's see an example, the clean rule.

!config
# Clean rule for arara
# author: Paulo Cereda
# requires arara 3.0+
identifier: clean
name: CleaningTool
command: <arara> @{remove}
arguments:
- identifier: remove
  default: <arara> @{isFalse(file == getOriginalFile(), isWindows("cmd /c del", "rm -f").concat(' "').concat(file).concat('"'))}

Using this directive

% arara: clean: { files: [ foo.aux, foo.log ] }

will make arara remove two files, foo.aux and foo.log. There's an important check which prevents arara from removing the main .tex file if no files directive argument is provided. Say,

% arara: clean

does nothing.

Let's say we will replace the default instruction by

default: <arara> @{isWindows("cmd /c del", "rm -f").concat(' "').concat(file).concat('"')}

If we try

% arara: clean

the main .tex file (possibly foo.tex) will be gone! Neat isn't it? :)

Of course, we are talking about a faulty rule.

arara has the following workflow:

1. Read all directives.
2. Find their corresponding rules.
3. Expand directives into commands.
4. Run all commands.

That's the basic idea behind the program.

It might be worth mentioning that the program makes use of a library to execute these external commands which doesn't allow subshell calls.

Anyway, I really don't know what else to say. :) We are all vulnerable to malicious packages, but that's a risk we need to take. Thankfully, source code has to be available in order to hit CTAN (not entirely true, but true for packages), so we can always check entries for suspicious elements.

As I said, LuaTeX for example allows I/O from Lua, which can also be dangerous. We are exposed to some level of threat at some time, it depends our use. :)

And running arara (or any program) in a server without a sandbox... ouch. :)

Answer 2

shell escape will enable pdflatex to save, write, delete and call another program from the system. Some times this can be dangerous as malicious code may be called and executed, endangering the system.

Arara, on the other hand, executes the directives, written by the user, inside the documents. Without a directive, nothing is executed. These directives, written by more of a lovely human (;-), are more human readable. For example if the directive says arara: pdflatex: {shell: yes}, then it is a YES to shell escape and NO otherwise.

In a nutshell,

1. If you have a directive to use shell escape, only then it will be used.

2. These directives are found at the top of your source and are easily readable. If you didn't write those directives, you can easily disable the option by putting a no and be safe and happy.

3. An added advantage of using arara is that you can selectively enable shell escape to a particular document.

Hence, I feel that using arara is safe noting that the author is a good friend of mine ;-).

Answer 3

In general, I think of pdflatex as being pretty safe since it can really only read and write files. I understand TeX is Turing complete and you can make it make toast, but I think it would take a lot of work to do something malicious. On the other hand, arara has full access to the command line and I think with relatively little work can be made to do bad things. The type of security hole I was thinking about can be seen with the following example that doesn't fully work

% arara: pdflatex
% arara: pdflatex
\documentclass{article}
\usepackage{filecontents}

\begin{filecontents*}{pdflatex.yaml}
!config
identifier: pdflatex
name: pdflatex
command: touch temp.txt
arguments:
- identifier: target
  flag: <arara> @{parameters.target}
\end{filecontents*}

\begin{document}
Hello World
\end{document}

The idea is that the filecontents environment is used to overwrite the arara pdflatex rule to do something malicious. To be malicious you would need to replace the benign touch temp.txt and obfuscate the filecontents, but neither of those should be too hard.

The idea behind the attack only works if tex can write to the arara rules directory. I think this is a major limitation, since I believe there are pretty strong constraints on where pdflatex can write. That said, my intended use of arara was for the current directory to be added to the arara rules path.

The reason that the attack doesn't fully work is that the second arara pdflatex directive does not invoke the new pdflatex rule which has been written by the filecontents environment, but rather uses the original rule. The attack is still successful in the the overloaded rule is written and the next time arara is run the malicious rule is used. This behavior is somewhat surprising to me and I am not sure it is intended. Nevertheless, it is useful as a security precaution.