Re: Should mounting a font be able to escape a font path directory?

[G. Branden Robinson]

Hi, Ingo!

At 2021-11-05T15:06:30+0100, Ingo Schwarze wrote:
> > Should our font-opening logic refuse to traverse directories?
> [...]
> > 1.  Why not?  groff is an unprivileged process.
> 
> That is incorrect.  I'm sure you have seen sysadmins type "man"
> in a root shell, too.

I was having trouble thinking of reasons to _keep_ the existing
behavior, so I confess I grasped a little bit for this one.  It came
readily to mind because I've so often _heard_ it.

Some of my "con-" arguments were overloaded, too, I think--an arbitrary
amount of font description file data can be read before a bad `name`
directive is reached, so even if we were allowed to abandon processing
it at that point--and we're not--comments could have easily loaded the
line buffer with an attempt at shellcode.

> Needless to say, that does not necessarily cause havoc.  You usually
> need many favourable factors to combine their effects if you hope for
> a full-blown catastrophe.  But groff traversing directories and
> reading files it shouldn't can be one among these factors.
> 
> You are certainly aware that mandoc is more paranoid than groff in
> such respects - still, as one data point: mandoc does not even accept
> absolute paths or paths containing "/.." or "../" in .so requests and
> similar places.  Even though in such places, such features are
> arguably more useful than when it comes to font description files.

Yes--if all you're rendering is man pages, most or all traditional uses
of the `so` request (in a _document_) are inappropriate.  A man page is
not supposed to be a complex document with respect to file storage.

[...]
> I think being cautions with what you accept is a virtue.
> 
> Before aupporting a feature that can obviously serve as a building
> block for vulnerabilities, it would make sense to me to ask for
> a rigourous explanation why the feature is absolutely needed and
> why the intended effect cannot be achieved in a safer way.

Thank you for your perspective.

I've committed the change, with a regression test.

I have not yet added a diagnostic message to the implementation of the
`fp` request; directory traversal attempts are, at present, _silently_
rejected.  This is because the meanings of the terms "internal name" and
"external name" are, in my opinion, underspecified, and we have a
humdinger of a terminology clash.

Quick quiz for anyone reading:

* In groff, do the terms "internal name" and "internalname" refer to the
  same thing?

If you think you know, go to Savannah #61423[1] and see!

Regards,
Branden

[1] https://savannah.gnu.org/bugs/index.php?61423

signature.asc
Description: PGP signature