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

[Ingo Schwarze]

Hi Brandon,

G. Branden Robinson wrote on Fri, Nov 05, 2021 at 01:48:02AM +1100:

> A change I made to add validation of the "name" directive in font
> description files[1] inadvertently broke something Dave Kemper has been
> doing for a while[2].  It also turns out to have probably foreclosed
> unintentional directory traversal[3].
> [1] https://git.savannah.gnu.org/cgit/groff.git/commit/?id=c0d1bb28
> [2] https://savannah.gnu.org/bugs/?61423
> [3] https://savannah.gnu.org/bugs/?61424

[...]
> Should our font-opening logic refuse to traverse directories?  I can't
> get Heirloom Doctools troff to do it, but I haven't tried as hard as I
> can.

[...]
> 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.

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.

> But I don't want to make users do this sort of thing just because.  My
> predilections are prescriptivist and paranoid; perhaps plenty of people
> perceive a paucity of problems here.

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.

Yours,
  Ingo