Follow-up Comment #7, bug #66419 (group groff):

I agree that the basic problem is the re-use of code to access completely
different font files. .fp references groff font files which will be parsed
(and only "belong" to groff), so there is a potential attack vector, but
entries in the download file point to actual real postscript fonts (available
to all programs on the system) which will either be valid and work, or invalid
and fail, but never in a way which could compromise the system. You can of
course have valid and malicious postscript fonts which when downloaded to a
printer cause it to calculate pi to the nth degree as an actual postscript
program, but checking for "/" in the path would not stop that!

The download file for devpdf continues to allow full pathnames, since even a
malicious type 1 font will get nowhere, because the PDF spec does not include
a postscript interpreter, and an invalid type 1 font file is likely just to
make gropdf give up on the document.

If you fear a security hole in the .fp request by all means plug it, but it is
a poor choice if it prevents paths being included in the grops download file


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?66419>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

Attachment: signature.asc
Description: PGP signature

Reply via email to