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
