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

[G. Branden Robinson]

Hi all,

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].  (The font file is still _opened_,
but it is rejected and no font is mounted unless the font name _exactly_
matches the second argument to .fp, as a string, with the correct number
of dots and slashes.)

My question is simple:

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.

Arguments for continuing to permit opening of arbitrary relative file
names with .fp requests:

1.  Why not?  groff is an unprivileged process.
2.  There's probably nothing you can do with an "evil" font description
    file that can't be done more easily with untrusted roff input in the
    first place, with requests.  (You can remap any character with .char
    and .tr and friends, you can screw up the spacewidth with .ss, and
    so on.)
3.  A person with a malicious input document can always advise a user,
    who lacks mastery of groff's -F option and GROFF_FONT_PATH
    environment variable, to manipulate these parameters to cause a
    cooperating malicious font description file to be loaded anyway.

Arguments for prohibiting opening of arbitrary relative file names with
.fp requests:

A.  We already claim to be running in "safer" mode by default.  I don't
    think this hack was anticipated.  Maybe James Clark knew of it, as
    I have a guess that the whole reason he omitted validation of the
    "file" directive was due to the way file names are spelled on MS-DOS
    systems.  (Apparently MS-DOS was actively supported by groff in
    1990.)  One cheap way to avoid worrying about the directory
    separator character is by not validating strings that contain it.
B.  A file open is a file open, and safer mode prohibits the .open
    request among others.
C.  Even though libgroff only opens a font description file for reading,
    it does still read the entire file (and is obliged to due to the
    specification of the file format)  It's not impossible that an
    attack on a different groff function could take advantage of
    arbitrary data in a font description even if it is syntactically
    invalid and doesn't get loaded.
D.  Glyph names are pretty loosely specified.  Many surprising
    characters are legal in them.  Every font file is allowed to define
    as many glyph names as it wants.
E.  Opens of _absolute_ file names (i.e., beginning with "/") are
    already prohibited[4].  But you can always get to the root directory
    with enough "../"s, as we learned the hard way in the 1990s with FTP
    server software.  Why close this channel but leave the other one
    open, unless it was unintentional?

I told Dave that he might be better off moving the effectively
documentary "file" directives in his menagerie of devps font
descriptions to a comment or unrecognized directive name (those are both
valid; see "Device and Font Descriptions" in our Texinfo manual, or
groff_font(5)).

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.

Opinions?

Regards,
Branden

[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
[4] This may be more due to good fortune than security-minded thinking;
    it is a consequence of prefixing the requested font description file
    name with, e.g., 'devps/'.[5]
[5] 
https://git.savannah.gnu.org/cgit/groff.git/tree/src/libs/libgroff/fontfile.cpp#n64

signature.asc
Description: PGP signature