Re: Braindump: Can we get rid of the font-cache-group question?
On Fri, Jun 02, 2006 at 14:01 +0200, Florent Rougon wrote:
> Hmmm. Looking at the code you posted, I think it would fail except if
> attacking through "$TFMDESTDIR/tfm$$.tmp" when cp is used instead of mv
> (presumably a rare case, only happening on DOS). The reason is that if
> bar is a symlink, 'mv foo bar' replaces bar, instead of following it. Of
> course, if that was so easy, we wouldn't have to use mktemp ever. The
> problem is reported a bit earlier, when the mv'ed file is created (here,
> $TFMNAME). If it is created in world-writable temp dir, then the attack
> can happen there, because $TFMNAME is predictable.
Indeed, thanks for the correction.
> But here, I think it is created in the current directory, right? If this
> directory is world-writable, same problem. Otherwise, though it's a bit
> ugly to fill the current directory this way, the attack cannot work,
> AFAIS.
Yes, the files are created in the current directory. So we are actually
save as long as the current directory is not world writable (and the mv
does not fail so that cp has to be used). Considering all the many files
that are created during normal use, using TeX and especially LaTeX in a
world writable directory is stupid because it offers so many
possibilities for attacks. I don't think it is worth taking care of the
problem of autogenerated fonts without taking care of the other issues
as well.
Or maybe not. In texmf.cnf we have
% Allow TeX \openin, \openout, or \input on filenames starting with `.'
% (e.g., .rhosts) or outside the current tree (e.g., /etc/passwd)?
% a (any) : any file can be opened.
% r (restricted) : disallow opening "dotfiles".
% p (paranoid) : as 'r' and disallow going to parent directories, and
% restrict absolute paths to be under $TEXMFOUTPUT.
openout_any = p
openin_any = a
However, metafont does not semm to honour these settings. I still think
that working in a world writable directory is a bad idea. But a RFE for
metafont might still make sense. I don't think it makes sense trying to
catch this in the mktex* scripts.
> > ? (ignoring DOS and its problems with mv for the moment)
>
> I don't know. BTW, what is it about DOS here? A /bin/sh port for DOS?
> Because DOS doesn't have cp, chmod...
I was only refering to the comment in the code about DOS having problems
moving files to deeply nested directories. I have no idea what problem
this comment is refering to.
cheerio
ralf
Reply to: