[17393] in Athena Bugs
dvips safety holes
daemon@ATHENA.MIT.EDU (Jamie Morris)
Mon Nov 29 23:26:48 1999
Message-Id: <199911300426.XAA397580@steve-dallas.mit.edu>
To: bugs@MIT.EDU, bug-newtex@MIT.EDU
cc: template-dev@MIT.EDU
Date: Mon, 29 Nov 1999 23:26:32 -0500
From: Jamie Morris <jemorris@MIT.EDU>
One definite bug in non-newtex dvips, and one probably-bug in
both newtex and non-newtex dvips.
1) non-newtex only: -R lies
/usr/athena/bin/dvips --help lists
R Run securely
as does /usr/athena/lib/tex/macros/dvips.tex.
For some reason, neither dvips.tex nor the non-newtex manpage actually
expound upon that (probably also a bug), but they do have the option,
which I'm confident should obey the description in the newtex manpage,
-R Run in secure mode. This means that ``backtick''
commands from a \special{} or \psffile{} macro in the
(La)TeX source like \special{psfile="`zcat foo.ps.Z"}
or \psffile[72 72 540 720]{"`zcat screendump.ps.gz"}
are not executed.
without which a .dvi file someone gives you can execute arbitrary commands
in the shell when you dvips it (whee!).
Anyway, /usr/athena/bin/dvips claims to obey -R when I use it, but
it executes the escaped command *anyway*. Using
By the time you read this, I've already zephyred you.
\special{psfile="`zwrite $USER -m tex talks! >/dev/null"}
\supereject
\bye
as zephyr.tex, I get
steve-dallas> /usr/athena/bin/dvips -R zephyr -o
Message queued for jemorris... sent
This is dvips 5.76 Copyright 1997 Radical Eye Software (www.radicaleye.com)
' TeX output 1999.11.29:2303' -> zephyr.ps
<tex.pro><texps.pro><special.pro>.
</afs/athena.mit.edu/contrib/tex-contrib/BaKoMa/pfb/cmr10.pfb>[1
/usr/athena/bin/dvips: Failure to execute zwrite $USER -m tex talks! >/dev/null; continuing
]
which clearly claims to be disallowing the special, and yet I also
get a "tex talks!" zephyr. If I use the newtex dvips with the same
file and command line, it gives the same "Failure to execute" and
actually means it (no zephyr).
2) In both newtex and non-newtex, but it may not technically be a bug:
When dvips starts, it searches TEXCONFIG (defaulting if not set) for a
config.ps master configuration file and obeys it. If ~/.dvipsrc
exists, it obeys that too. If it later decides on a printer to send
to, it reads config.printername also.
In any of these, lines of the form
E zwrite jemorris -m the config file speaks
E zwrite $USER -m So you're printing to meadow, are you?
do what you're guessing. -R disables E-lines _after dvips gets to it_
--- that is, you can disable them in config.printername files this way,
but not in config.ps, as that gets read right away.
The default search path for config.ps for both newtex and non-newtex
dvips starts with "." (well, it does for newtex; for non-newtex I can't
ask kpsewhich --show-format=34 to tell me for sure, but it reads my
./config.ps file, so it's certainly *early* in the path). As people
often cd to other people's dirs to dvips things there, this is a security
hole for the same reason having . early in your PATH is; I can put a
malicious config.ps along with my .dvi files, and many people will happily
cd in, dvips, and send me copies of all their personal files and post
obscenities to Usenet.
It is presumably for this reason that dvips.tex states
\o E command:
Execute the system command listed, for example as a UNIX shell command.
Execution takes place immediately, while the configuration file is
being read. This option can be used to insert the current date into a
header file, for instance, as explained at the end
of section~13.
>>>Possibly dangerous; in many
>>>installations it may be disabled, in which case a warning message will
>>>be printed if the option is used.
So, I'd state the maybe-bug as some variant on
(a) E isn't disabled, allowing the malicious ./config.ps described above
(b) . is early in the default search path; if it weren't, this problem
wouldn't exist and the user could still use E if they wanted
by setting TEXCONFIG
(c) -R doesn't turn off E lines in config.ps
(b) is my favorite to fix, followed by (c), followed by (a). However, it
may be the most counterintuitive from documentation; the default path
that dvips.tex gives is not the one used on athena, but does have dot first.
(b) gives users default safety and lets them have more rope on request.
It also protects them from malicious -o defaults (eg "by default, dvips
will overwrite your ~/mbox" (at least it can't do dotfiles, I think)).
(c) doesn't give them default safety, but at least lets them get it,
though they can't both -R the .dvi file and choose to use E configs;
OTOH I'm not sure it's possible :)
(a) gives default safety, but doesn't let you ask for more rope.
If you agree that this is a sufficient breach to warrant one of those,
I'd like to see newtex and non-newtex take the *same* solution, please :-)
Jamie
