[XeTeX] How to manually create the xelatex.fmt?

[Chris Travers]

2011/10/20 Zdenek Wagner <zdenek.wagner at gmail.com>:

> I have server side applications based on TL. I use them from time to
> time (none of them is currently active). The remote user cannot write
> the document, it is always prepared by some SW tool (PHP, XSLT, ...).
> And \write18 is disabled for such applications. On the other hand,
> there are servers providing TL and users can type their documents
> directly, see http://tex.mendelu.cz/ for instance.
>
> If the current version of TL is 2011 but the native packaged version
> in a Linux distro is 2007, are you sure that there are not bugs and
> security holes? Do you know how \write18 is handled? Are you sure that
> they do not allow \input /etc/passwd and \input /etc/shadow? It is
> disabled by me in my TL based server side applications.

Ok, two quick points I can't help but pass up.

1)  Any server programmer worth his salt is going to properly sanitize
user input before putting it into a template.  I am not 100% confident
that we do a perfect job, but I can tell you that if \write18 or
\input /etc/passwd ended up in an invoice it would be the sysadmin, or
a third party developer contracted to build templates, and not the
user who put it there.   We do the same for HTML because we don't want
nasty little things like cross-site scripting.  If you allow users to
input arbitrary code into your templates, you get what you deserve.*

* There is a caveat here in that the software does allow a subset of
users to edit the templates, including the latex commands, but this is
disabled by default on the filesystem level and for good reason.
There are few users who find this is worth the inherent security
risks, but there are a few.

2)  If your accounting system has access to /etc/shadow, I think the
fact that it could be input into a LaTeX document is the least of your
worries.  Seriously. there is something to be said about server
software running with restrained permissions (which is why the Apache
worker processes run with limited permissions, why PostgreSQL refuses
to run as root, etc).....

We started LedgerSMB because we were focused on security and the
project we forked from was not.  This means restricted permissions,
input sanitation, and the whole bit.  Heck the most recent version of
our software doesn't even have permission to access the database if a
user isn't logged in, and then it only has the permissions granted to
that user (meaning that SQL injection issues, if they exist, are
suddenly a lot less interesting).

As your examples demonstrate, without input sanitation, and restrained
permissions, the ways in which a programming language can be abused
are just too difficult to prevent.  The solutions are banning *all*
escape sequences, and running with no more permissions than absolutely
necessary.  Then these problems go away.

The nastier bugs (and ones that other libraries may have a role to
play in addressing) occur when invalid data is sent to the template
and this causes processing errors, such as buffer overflows, stack
overflows, and the like.  In these cases, it could be possible to
attack such a system without passing in LaTeX commands.  Replacing the
underlying faulty library fixes the problem, which of course is
impossible when everything is statically linked.....

Best Wishes,
Chris Travers