secure TeX from CGI

39 Aufrufe
Direkt zur ersten ungelesenen Nachricht

Robert C. Helling

ungelesen,
20.10.1998, 03:00:0020.10.98
an
Hi,

I would like to TeX a document from a CGI script that contains portions
of text that a user supplied thru a html form. The user shold have the
possibility to enter TeX commands as for special symbols like accents.

On the other hand, the potential user is not trustworthy. So I don't want him
to write any files from TeX, say. A potential problem would be something like

\openout1=.login
\write1{rm -rf ~*}
\closeout1

Imagine this is beeing TeXed and then R.J. Dorfnat logs in as owner of the
webserver to do some CGI debugging and finds his home dir empty!

So I want to make sure no other files are opened for writing and no shell
commands are executed (possible from TeX? perhaps via weired font generation?)

How can I do this? The idea would be to delete all occurences of \openout,
say. But this can be circumvented by some macro constructions that
construct the token \openout without containing it literally...
Some other idea would be to overwrite the definitions of the dangerous
commands before the user supplied code is inserted, like

\def\write{\relax}
\def\openout{\relax}

etc. Has anybody thought about this problem before? Can you think of a complete
list of possibly harmful commands? Is font creation possibly dangerous?
Would it be harmful if the user himself redefined commands that are executed
later like \end, say? So do I have to prevent the user from defining macros?
What about changing character codes? Like making E behave like \?

Sometimes TeX variablity is not very handy....

Any input is wellcome!


Robert


--
.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oO
Robert C. Helling Albert Einstein Institute Potsdam
Max Planck Institute For Gravitational Physics
and
2nd Institute for Theoretical Physics
DESY / University of Hamburg
Email hel...@x4u2.desy.de Fon +49 40 8998 4706
<href=http://www.aei-potsdam.mpg.de/~helling>

Richard Kinch

ungelesen,
21.10.1998, 03:00:0021.10.98
an
Robert C. Helling <hel...@x4u2.desy.de> wrote:

> On the other hand, the potential user is not trustworthy. So I don't want him
> to write any files from TeX, say.

TeX has to write files to any substantial work.

One approach: modify openout to open only relative filenames at or below the
launch directory; then invoke the CGI TeX in a temporary directory.

Richard J. Kinch
Publisher, TrueTeX brand typesetting software.
See http://truetex.com

Richard Kinch

ungelesen,
21.10.1998, 03:00:0021.10.98
an
Richard Kinch <tru...@IDT.NET> wrote:

> TeX has to write files to any substantial work.

Shoulda said, "to *do* any substantial work."

Kasper Peeters

ungelesen,
21.10.1998, 03:00:0021.10.98
an

> So I want to make sure no other files are opened for writing and no shell
> commands are executed (possible from TeX? perhaps via weired font
> generation?)

Web2c has options to disable reading outside a given directory tree,
and Olaf Weber has supplied me with a patch to disable writing as
well. Not entirely safe (you can still play dirty font tricks) but
better than nothing.

(I will mail you with details privately)

Kasper


Boris Tobotras

ungelesen,
22.10.1998, 03:00:0022.10.98
an
>>>>> "Kasper" == Kasper Peeters writes:

>> So I want to make sure no other files are opened for writing and no
>> shell commands are executed (possible from TeX? perhaps via weired font
>> generation?)

Kasper> Web2c has options to disable reading outside a given directory
Kasper> tree, and Olaf Weber has supplied me with a patch to disable
Kasper> writing as well. Not entirely safe (you can still play dirty font
Kasper> tricks) but better than nothing.

What's wrong with running TeX under chroot'ed CGI environment?

--
Best regards, -- Boris.

Kasper Peeters

ungelesen,
22.10.1998, 03:00:0022.10.98
an

> What's wrong with running TeX under chroot'ed CGI environment?

That way, the outside user can still read or write any arbitrary
file in the chrooted environment. If there is a single file in that
environment which has to be writable by the server, it is at risk.
Not nice.

Web servers that serve html pages also don't rely exclusively on
chroot for security.

Kasper

Allen antworten
Dem Autor antworten
Weiterleiten
0 neue Nachrichten