On 12/28/05, <b class="gmail_sendername">Reinhard Kotucha</b> <<a href="mailto:reinhard.kotucha@web.de" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">reinhard.kotucha@web.de</a>> wrote:<div><span class="gmail_quote">
</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
>>>>> "George" == <<a href="mailto:gnwiii@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">gnwiii@gmail.com</a>> writes:<br><br> > If you block absolute paths then you have to block relative paths
<br> > like [../]^N for N larger than the current depth, since those are
<br> > effectively the same as absolute paths.<br><br>They are similar, but not equivalent. If absolute paths are<br>disallowed, what can be damaged if you "cd /tmp" before you execute<br>anything?</blockquote>
<div><br>Some sites don't allow users to write in /tmp (they have to use $HOME/tmp) <br>both to avoid information leakage and the problems when some users process fills /tmp.<br><br>If you allow [../]^N then you don't need absolute paths to get at
<br>
files above /tmp.<br>$ cd /tmp<br>$ ls -i /etc/passwd ../../../../../../etc/passwd<br>13075025 /etc/passwd 13075025 ../../../../../../etc/passwd<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> Where security is concerned, simplicity is an advantage,<br><br>That's true. And it is helpful when similar programs behave similar<br>(regarding configuration), see below.<br><br> > so I don't see a reason to change from the current behaviour.
<br><br>Again, see below.<br><br> >> I still have to make that change to dvips, but I will when we<br> >> have moved away from p4.<br> >><br> >> Unless of course everybody else thinks this is a bad idea.
<br><br> > I think it is a bad idea, but then I tend to think dvi-anything<br> > that requires maintenance is a bad idea. I hardly ever use dvi<br> > anymore except to track down other people's problems. If we make
<br> > dvips secure enough so it can't do anything useful then people<br> > will stop bothering me.<br><br> > My pdftex-1.30.5 handles images with absolute paths -- is there a<br> > mechanism to block absolute and upwards relative paths in pdftex?
<br><br> > Time might be better spent considering how to deal with absolute<br> > paths in pdftex and/or improving the documentation.<br><br>Why doesn't dvips use openin_any from texmf.cnf?<br>______________________________________________________________________
<br>% Allow TeX \openin, \openout, or \input on filenames starting with `.'<br>% (e.g., .rhosts) or outside the current tree (e.g., /etc/passwd)?<br>% a (any) : any file can be opened.<br>% r (restricted) : disallow opening "dotfiles".
<br>% p (paranoid) : as 'r' and disallow going to parent directories, and<br>% restrict absolute paths to be under $TEXMFOUTPUT.<br>openout_any = p<br>openin_any = a<br>______________________________________________________________________
<br><br>I do not see a good reason why dvips cannot use them. They can be<br>overwritten on the command line. The default values in tetex and TL<br>are quite reasonable. I then suggest *not* to set the z-option in any
<br>
config.* file. Then graphics inclusion in pdftex and dvips will have<br>the same restrictions and there is only one place where this has to be<br>configured.<br><br>Karl, your suggestion<br><br> > 0) anything goes;<br>
> 1) absolute/relative paths ok, shell escapes not ok;<br> > 2) nothing ok.<br><br>is very similar to what we already have for *tex.<br><br>BTW., shell escapes had been removed from dvips some time ago.<br>libgz is now compiled into the binary so that dvips still can include
<br>compressed graphic files. No security problems are to be expected<br>here.<br><br>Hans, I do not see any advantage for something like parentlevel=2.<br>People might set this variable to a reasonable value and then forget
<br>that this variable exists. But most people will not be aware if this<br>and then wonder why ../../graphics/blabla/ works but<br>../../../graphics/blabla/ fails. And people do not care about the<br>directory where they execute files. I vote for not implementing this
<br>variable to keep things simple.<br><br>I do not see any big security problems with dvips at all: The user<br>decides where dvips output goes. This cannot be specified in a dvi<br>file.</blockquote><div><br></div>It is question of policy -- code that might be run on files downloaded
<br>from the net should not be able to read sensitive files such as those in /etc. <br>A mechanism that prevents '../../' from reaching the root directory<br>might be less problematic.<br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
For input files this is a bit more difficult, a PostScript file can
<br>have arbitrary PostScript code inside which allows reading and<br>creating arbitrary files. But this code is not executed by dvips.<br>The security settings in ghostscript are quite restrictive and I<br>suppose that you cannot destroy anything if you try to open a file in
<br>a printer.<br><br>It does not matter very much from which directory an included graphic<br>file comes. A bit more has to be done to make an included graphic<br>harmful. Only if you provide a PS header which redefines the graphic
<br>file inclusion code in dvips, then you can probably make something<br>like \includegraphics{/etc/passwd} work. And you also have to<br>redefine \includegraphics so that it doesn't insist on having a<br>%%BoundingBox comment in /etc/passwd. Good luck!
<br><br>It is much easier to insert malicious PS code into the graphics file.<br>But this cannot be prevented by dvips. This code has to be executed<br>by a PS interpreter.<br><br>However, if you are still concerned about security issues, what has to
<br>be done to make things absolutely secure?<br><br>A few years ago I was wondering what can be done with Type1 fonts.<br>Did you know that you can add a PostScript SPECIAL to a virtual font<br>which contains arbitrary PS code,
i.e. which creates an arbitrary file<br>when this font is processed by a PS interpreter? I did this<br>successfully. Well, you explicitly have to use the -dNOSAFER option<br>in ghostscript. Otherwise, all you'll get is an error message.
<br><br>I tried this many years ago and all I can tell is that gs had been<br>absolutely secure at this time. Today, gs developers are much more<br>paranoid, which is somtimes a bit annoying.<br><br>Can anyone imagine a situation where dvips is a security problem
<br>rather than the PS interpreter?</blockquote><div><br>History shows us many failures to imagine situations that turned out to be<br>security problems. "Paranoid" configurations are for sites that aren't <br>
willing to rely on imagination.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">What do you think about using the value of openin_any as a default and
<br>removing all variables which provide such restrictions from dvips'<br>config.* files (if necessary)? Users can add them if necessary,
<br>though I don't know a good reason.<br><br>George's statement "simplicity is an advantage" is not only true if we<br>talk about security. If similar programs can be configured the same<br>way or can even share the same variables in the config file, it is
<br>easier for users to understand how the system works, and it is of<br>course easier to maintain the documentation.</blockquote><div><br>The issues are not unique to TeX, so it may be worth looking for <br>examples in other packages.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Another thing is confusing:<br><br>dvips looks for a file ${HOME}/.dvipsrc<br>
<br>We have now $TEXMFHOME in all web2c based distributions and I think
<br>that dvips should look there instead. It should be sufficient to set<br>the variable $DVIPSRC properly in texmf.cnf (see page 16 in the dvips<br>manual). It is highly desirable if this file will not be hidden,<br>i.e
. it's name doesn't start with a dot.<br></blockquote></div><br>More good points!<br clear="all"><br>
-- <br>George N. White III <<a href="mailto:aa056@chebucto.ns.ca" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">aa056@chebucto.ns.ca</a>><br>Head of St. Margarets Bay, Nova Scotia