20030112 breaks dvips -o |lpr
Hi, using 20030112 pretest, dvips can't write output to pipes anymore: turtle fdp dvips -Php11 Protokoll_Regelkom_021217.dvi -o '| lp -dhp11' This is dvips(k) 5.92a Copyright 2002 Radical Eye Software (www.radicaleye.com) ' TeX output 2003.01.16:1546' - | lp -dhp11 /usr/local/teTeX/bin/dvips: ! couldn't open output pipe and turtle fdp dvips -Php11 Protokoll_Regelkom_021217.dvi -o '! lp -dhp11' This is dvips(k) 5.92a Copyright 2002 Radical Eye Software (www.radicaleye.com) ' TeX output 2003.01.16:1546' - ! lp -dhp11 /usr/local/teTeX/bin/dvips: ! couldn't open output pipe pretest 20021116 still was ok (can print), but 20021216 already is broken and has the same problem... Harald Koenig -- I hope to die ___ _ before I *have* to use Microsoft Word., 0--,|/OOO\ Donald E. Knuth, 02-Oct-2001 in Tuebingen._/ / /OOO\ \ \/OOO\ \ O|// Harald Koenig \/\/\/\/\/\/\/\/\/ science+computing ag// / \\ \ [EMAIL PROTECTED]^ ^
Re: 20030112 breaks dvips -o |lpr
On Jan 16, Robin Fairbairns wrote: what os are you using? there's just been a report (on c.t.t) of this as a direct consequence of upgrading to rh8.0 I see this problem with SuSE 7.2 running 20030112 (teTeX was built on RedHat 6.2), and IRIX64-6.5 running beta-20021216. SuSE 7.3 running pretest-20021116 binaries built on RedHat 6.2 is fine. Harald Koenig -- I hope to die ___ _ before I *have* to use Microsoft Word., 0--,|/OOO\ Donald E. Knuth, 02-Oct-2001 in Tuebingen._/ / /OOO\ \ \/OOO\ \ O|// Harald Koenig \/\/\/\/\/\/\/\/\/ science+computing ag// / \\ \ [EMAIL PROTECTED]^ ^
Re: pdftosrc and texmf.in problem?
Atsuhito Kohda writes:
Hi,
I am one of tetex maintainers of Debian and we got a bug report
that please include pdftosrc in tetex-bin
It seemed only a slight modification of texk/web2c/Makefile.in
would make pdftosrc. Is there any reason that pdftosrc was not
made by default?
I'm not sure, actually.
Next problem is; I found in some Japanese web site (or home page?)
that said texmf.in should be changed in the following two lines.
XDVIINPUTS = .;$TEXMF/{xdvi,dvips//}
DVIPDFMINPUTS = .;$TEXMF/{dvipdfm,dvips//}
to
XDVIINPUTS = .;$TEXMF/{xdvi,dvips}//
DVIPDFMINPUTS = .;$TEXMF/{dvipdfm,dvips}//
If this is correct, please fix texmf.in
It doesn't matter one way or the other, as texmf/xdvi doesn't have
subdirectories.
--
Olaf Weber
(This space left blank for technical reasons.)
Re: 20030112 breaks dvips -o |lpr
Harald Koenig [EMAIL PROTECTED] writes: Hi, using 20030112 pretest, dvips can't write output to pipes anymore: turtle fdp dvips -Php11 Protokoll_Regelkom_021217.dvi -o '| lp -dhp11' This is dvips(k) 5.92a Copyright 2002 Radical Eye Software (www.radicaleye.com) ' TeX output 2003.01.16:1546' - | lp -dhp11 /usr/local/teTeX/bin/dvips: ! couldn't open output pipe and turtle fdp dvips -Php11 Protokoll_Regelkom_021217.dvi -o '! lp -dhp11' This is dvips(k) 5.92a Copyright 2002 Radical Eye Software (www.radicaleye.com) ' TeX output 2003.01.16:1546' - ! lp -dhp11 /usr/local/teTeX/bin/dvips: ! couldn't open output pipe pretest 20021116 still was ok (can print), but 20021216 already is broken and has the same problem... The same sort of brokenness is prevalent in RedHat-8.0's binary. I presume that some mistaken sense of security is the cause: if somebody is able to smuggle in a |badprogram into the command line, he'll also be able to smuggle in what it takes to let it take action. If the output file could be specified from within the DVI file, things would be different, but I can't for the life of it make sense of why this should be more secure? Suppose that dvips is run in some sort of spoolern with priviledges and you want to avoid having a user call some program by that way. But you never should then let the user transfer a file name by itself, or he could equally maliciously specify /etc/passwd as the target file. I just don't get it. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum
Re: 20030112 breaks dvips -o |lpr
[added Tomas Rokicki to the recepients, throwing him into this discussion] Hi, -o |lpr no longer works, because the default config file of dvips now correctly sets secure mode on. Secure mode can be turned off by putting z0 into a config file for dvips or by specifying -R0 on the commandline (that -R0 does not work in the dvips contained in RedHat 8.0 which makes the problem even worse there). When I decided to enable secure mode in dvips, I thought it was a good thing to make sure that command execution via special's is disabled by default. I was not aware that this includes almost all command execution of dvips (font generation is controled separately), including output pipes. So, I think that many teTeX users will be suprised if teTeX-2.0 comes with security on by default in dvips. Tomas, I don't think that the output pipe is a security concern, since it cannot be set via the dvi file. Do you think that you can change the implementation of secure mode to allow the output pipe? Thomas
Re: 20030112 breaks dvips -o |lpr
That's a very good point; if the *user* specifices -o |... that *should* override the security setting. What if the -o option comes from a config file; should that override the security setting? Probably not, because the override could come from a .dvipsrc file created by a malicious program . . . Gosh, there is lots of stuff that needs to be fixed in dvips; I'm very sorry for (possibly) holding up a new release. I'll make sure to spend some time this weekend on it . . . -tom
Re: 20030112 breaks dvips -o |lpr
only config files in trusted paths can be used for external commands etc. Sounds like we're getting closer to Perl's taint mode. In any case, this is the sort of thing we'd have to depend on kpathsea to provide, right? I don't see that happening in this release. Yet, not allowing o !lpr -P foo in a configuration file due to security restrictions is disappointing. Note that dvips *does* use the current directory in most of its search paths, so anyone can drop a config.ps as part of a dvi tarball that will be picked up by dvips. (Which is another issue, since security can be disabled in the config.ps, which is why originally dvips would never let you turn security *off* in config.ps . . .) Arghhh. -tom
Re: pdftosrc and texmf.in problem?
I am one of tetex maintainers of Debian and we got a bug report
that please include pdftosrc in tetex-bin
I see. pdftosrc was even included in good-old-teTeX-1.0... I have
just added
@PTEX@pdftosrc = pdftosrc
...tie $(ttf2afm) $(pdftosrc) ...
to texk/web2c/Makefile.in. Seems that this is sufficient.
Olaf, any objections?
XDVIINPUTS = .;$TEXMF/{xdvi,dvips}//
DVIPDFMINPUTS = .;$TEXMF/{dvipdfm,dvips}//
Olaf just has done this for web2c-7.4.4.
Thomas
Re: 20030112 breaks dvips -o |lpr
Thomas Esser [EMAIL PROTECTED] writes: That's a very good point; if the *user* specifices -o |... that *should* override the security setting. Good, we agree here. What if the -o option comes from a config file; should that override the security setting? In secure mode, dvips should not trust the dvi file. I don't see why dvips should stop trusting its configuration files. If these are messed up by some other security problem, then the user has lost already. kpsepath dvips_config .:!!/root/texmf/dvips//:!!/usr/local/share/texmf/dvips//:!!/usr/share/texmf/dvips// Bad. Bad, bad, bad. Default TeX security for normal execution prohibits TeX from writing to files in external hierarchies or files starting with `.'. IMO, config files should _never_ be looked for in the default directory. If they aren't, we are pretty safe from Trojans in TeX files. Where is the point in reverting to trickery in order to write stuff to some place where you could write them in the first place if you wanted to? So, I suggest not to disable the output pipe at all (no matter wether it was set by some config file or the command line). So do I. And complain to whoever thought it reasonable to search for config files in `.' (mine is currently provided by RedHat, probably some old teTeX 1.0.7). As long as config files are kept out of areas where TeX processes can write, I don't think it a security problem if one can specify output to a pipe. In particular, since you could in the same place specify output to /etc/passwd. I hope you get my point why I think config files should not be looked for in `.'. That would be great, indeed. I plan to release teTeX-2.0, soon (now that pdftex-1.10a *final* is out). -- David Kastrup, Kriemhildstr. 15, 44793 Bochum
Re: 20030112 breaks dvips -o |lpr
Dvips has *always* searched in the current directory first for virtually all files, config files, tfm files, vf files, figure files, header files, etc. So all the blame on that goes to me. This was intended as a feature; users sometimes want to override something, much like TeX searches for input files starting in the current directory and then moving on to the system directories and so on. From a security standpoint, this is clearly bad, as you say. But I'm not sure disabling search for config files in . is, at this point, a great solution. I'm sure many people use this extensively, and we will totally break them if we make this change. For instance, what about .dvipsrc, which is *intended* as a place for the user to specify default config options for dvips, and it is searched for in $HOME, which is often the current working directory of people running dvips as well? Man, what a mess.
Re: 20030112 breaks dvips -o |lpr
Tomas G. Rokicki [EMAIL PROTECTED] writes: What if someone untar's a paper distribution with a dvi file and associated figures, that contains a .dvipsrc file? Or config.ps file? Configuration files should not be searched for in the current directory. I am repeating myself here. And then runs dvips? In this case it's not TeX writing the output file, but we're still enabling an exploit. Now of course someone can do the same thing in general with a .bashrc file or .login file (assuming the user unpacks to the home directory, which is distressingly common). If a user unpacks something into his home directory where all sorts of configuration files are kept, TeX security is the least worry of the user. How about retricting the panicking to those cases where a user is acting in a remotely sane manner? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum
Re: pdftosrc and texmf.in problem?
Thomas Esser writes: I am one of tetex maintainers of Debian and we got a bug report that please include pdftosrc in tetex-bin I see. pdftosrc was even included in good-old-teTeX-1.0... I have just added @PTEX@pdftosrc = pdftosrc ...tie $(ttf2afm) $(pdftosrc) ... to texk/web2c/Makefile.in. Seems that this is sufficient. Olaf, any objections? Go ahead. -- Olaf Weber (This space left blank for technical reasons.)
Re: 20030112 breaks dvips -o |lpr
Giuseppe Ghibò [EMAIL PROTECTED] writes: Furthermore in output pipe we could have different level of security, so to have both tex users as well as unix sysadmin happy (the latter mainly because dvips is for instance used in some printer filter which could run with root privileges): 1) allow pipe output to any command 2) allow pipe output but only to a fixed set of commands (fixed in the sources and not modifiable in further config files: e.g. only /usr/bin/lp [in case of running cups or SysV] and /usr/bin/lpr). Too contrived, IMO. 3) don't allow any output to a pipe, but only to files What's the use of that distinction? If I can write any file I have access to, I don't need no fscking pipe to do my harm in the first place. 4) don't allow any output to a pipe Or one considers certain options security relevant and won't accept them from a file in a TeX-writable place (. or below or so). -- David Kastrup, Kriemhildstr. 15, 44793 Bochum
Re: 20030112 breaks dvips -o |lpr
Tomas G. Rokicki wrote:
Dvips has *always* searched in the current directory first for virtually
all files, config files, tfm files, vf files, figure files, header files,
etc. So all the blame on that goes to me. This was intended as a
feature; users sometimes want to override something, much like TeX
searches for input files starting in the current directory and then
moving on to the system directories and so on.
From a security standpoint, this is clearly bad, as you say. But I'm
not sure disabling search for config files in . is, at this point,
a great solution. I'm sure many people use this extensively, and
we will totally break them if we make this change. For instance, what
about .dvipsrc, which is *intended* as a place for the user to specify
default config options for dvips, and it is searched for in $HOME,
which is often the current working directory of people running dvips
as well?
Man, what a mess.
IMHO depends what is run as root and what isn't. From the point of view
of where a file is written but the output, the same things affecting dvips
affects tex, latex, etc.; now not talking about buffer overruns which recently
affected old dvips, but from point of view of pipes, if a user takes a whatever
.tar.gz file, which contains .dvipsrc or config.ps containing
o |rm -rf / (or o |rm -rf ~)
and runs the dvips file.dvi, is like telling him to execute a shell script
containing rm -rf /. The only difference is that it's not expected
that producing or printing a .dvi file could wipe out your home system
if running as root (either for output or in a special like
\special{psfile=`rm -rf /2}).
So from point of view of security default dvips configuration should
be the one allowing to:
1) protect files of non privileged users and also let him to work
without to many security complicances. This can be achieved disabling pipes (or
restricting only to a set of fixed commands [e.g. just lp, lpr for -o, and
'convert' for specials]). And not letting non-privileged users' per $HOME config
files or other options to override when PIPES were disabled in main config file
(of course they can turn off if pipes are by default enabled in main config
file). On the other hand the most common output to pipes are just to lpr or lp
(sometimes gv) and some converter (ImageMagick) or gzip for producing ps files
in psfile= specials). For gzip, honestly, with current hard disk sizes not
much people are compressing single .ps files... (also because they have then to
provide manual BBoxes).
2) protect the system when dvips run as root as filter. The filters should have
options to let all the pipes disabled.
Bye.
Giuseppe.
Re: 20030112 breaks dvips -o |lpr
Okay, so if we agree the solution is: 1. Allow the output pipe to be opened in all cases and 2. Never search for configuration files (config.ps, config.printer, and .dvipsrc are the only ones critical here) in the current directory then I've got some questions about dvips vs kpathsea. Who currently is responsible for defining the default paths for dvips? Is this still in dvips, or is this in texconfig, or kpathsea? Is it simply a matter of changing those defaults, wherever they live? -tom
Re: 20030112 breaks dvips -o |lpr
Giuseppe Ghibò [EMAIL PROTECTED] writes: 2) protect the system when dvips run as root as filter. The filters should have options to let all the pipes disabled. Don't see the necessity. root filters (like in line spoolers) are run in separate directories and with command line options specified by the filter programmer. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum
Re: 20030112 breaks dvips -o |lpr
Date: Thu, 16 Jan 2003 22:39:18 +0100 From: =?ISO-8859-1?Q?Giuseppe_Ghib=F2?= [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: 20030112 breaks dvips -o |lpr [and for special backtick, only allow a common set of commands at a fixed path, e.g. convert from ImageMagick] For format conversions, I prefer the approach used by xdvi: Instead of backtick, just put the file name there, and have the application recognize the format and run the appropriate converter. For example, in xdvi, if a \special refers to a file whose name ends in .Z or .gz or .bz2, and if the file begins with the right magic number, then xdvi will automatically run uncompress -c, gunzip -c, or bunzip2 -c (respectively) on the file. Regarding o |rm -rf / in config files, I would suggest that the behavior depend on the config file. For example, a config file in . would be regarded as unclean, and o |command in such a config file would be rejected, but a config file in /usr/local/texmf/dvips/config would be regarded as clean and dvips would allow o |command in such a location. --Paul Vojta
Re: 20030112 breaks dvips -o |lpr
Don't see the necessity. root filters (like in line spoolers) are run in separate directories and with command line options specified by the filter programmer. Full ACK. Whoever writes such a filter should know what he is doing and put something like an explicit -f or -o argument into the commandline of dvips. Thomas
Re: 20030112 breaks dvips -o |lpr
Giuseppe == Giuseppe Ghibò [EMAIL PROTECTED] writes: Furthermore in output pipe we could have different level of security, so to have both tex users as well as unix sysadmin happy (the latter mainly because dvips is for instance used in some printer filter which could run with root privileges): Are there any systems where printer filters has to run with root privileges? On my sytem it's run as user lp which is, of course, more secure. zarniwoop:# su - lp lp@zarniwoop:~$ touch /etc/passwd touch: /etc/passwd: Permission denied Furthermore, it doesn't make much sense to run dvips from a printer filter if it receives the dvi file from a pipe. In this case, included graphics get lost. Reinhard -- Reinhard Kotucha Phone: +49-511-27060390 Marschnerstr. 25 D-30167 Hannover mailto:[EMAIL PROTECTED] Microsoft isn't the answer. Microsoft is the question, and the answer is NO.
