Re: Help wanted evaluating claimed security vulnerability in groff

"G. Branden Robinson" <[email protected]> Thu, 28 May 2026 22:11:26 -0500
Newsgroups	gmane.comp.printing.groff.general
Message-ID	<20260529031126.yqo3wez2xgtd3igu@illithid>
Hi Larry,

At 2026-05-28T22:13:49-0400, Larry Kollar wrote:
> > G. Branden Robinson <[email protected]> wrote:
> > 
> > At 2026-05-27T00:29:36+0100, Deri wrote:
> >> The report is correct, the proof of concept "works".  I'm not sure
> >> about the severity though, groff runs at the users priority and the
> >> example is run using a font directory belonging to the user, so any
> >> commands you put in DESC have the same rights as if you typed them
> >> at the shell yourself.
> > 
> > Right.  There's _no privilege escalation_ here that I can see.
> > Since groff is already unprivileged and nowhere calls setuid(2) or
> > setgid(2), complaining that someone can run an arbitrary command via
> > a file on the file system to which the user already presumptively
> > has write permissions (a custom DESC file or, a pre-existing
> > compromise of superuser privileges leading to replacement of a
> > _system_ DESC file), the report feels kind of like saying, "the
> > shell is a security hole because it can run arbitrary commands".
> 
> I don't think a user would be terribly happy with the results of `rm
> -rf ~/Documents` or something similar.

I agree.

> Running as the user, who needs privilege escalation?

I think I failed to openly reason out how a "command injection" is made
possible by the reported behavior when there isn't already a vector that
has has to be exploited to exercise it, and which is more general.

Two of the tent poles of my thinking are (a) a specific anti-pattern and
(b) a usage scenario.

(a) The anti-pattern: "Hey!  Thanks for reading my book!  Type this in!"

    curl https://example.com/foo.sh | bash

    That makes me cringe every time I see it, and you can find it all
    over the Web and books by technical publishers.  If you can get
    somebody to type that, the data they can access at their existing
    privilege level is at your mercy.

(b) The usage scenario: "I've attached a *roff document to this email.
    Please review."

    This scenario is why GNU pic(1) and troff(1) have had "safer mode",
    and defaulted it on, for decades.

So how does the report manifest a case of (b)?  It doesn't.

To carry out an attack, you have to:

1.  Send the user a malevolent "DESC" file, and at least one font
    description file, and a *roff file payload.  The last two might be
    neutral, i.e., not malevolent.

2.  Convince them to install it onto their system.

3.  Convince them to run groff(1) with flags such that the malevolent
    DESC file will be found and used to render _and print_ a document,
    meaning you need to get the user to add `-F` and `-l` flags, and
    possibly a `-T` argument and option as well, the first with an
    argument corresponding to the installation location in step 2.

I don't know of an email client (MUA) that makes both steps 2 and 3
easy, and facilitates manipulating them in coordination such that the
attack will work.  Whether an attachment is downloaded at all is up to
the user, or is placed in a sandbox directory by the MUA with a
hard-to-predict name, and achieving step 3 requires retrieval of that
location by the user and customization of the groff command line.  I
don't know of an MUA (though I don't use many) that permits both
customization of that command line and for an untrusted source to
pre-populate it.

With (Neo)mutt, for example, /etc/mailcap governs how an
"application/x-troff-man" gets handled.  I reckon you can override this
with $HOME/.mailcap and/or $XDG_HOME_CONFIG/mailcap.  But how is the
malevolent payload going to do that?

Similarly, with (Neo)mutt, you can just straight up pipe an email (or an
attachment thereto) through an arbitrary shell command...that YOU type.
I don't know of an MUA that gives control over the population of that
command line to an untrusted external source.

When I game out scenarios in my mind, I struggle to think of any where a
real-world attacker wouldn't just send the victim, via the same vector
that this suggested exploit would use, a malevolent shell script, and
invite them to run that.  Or a *roff document and tell the user to run
it with `-U` to enable unsafe mode.  You can get to "rm -rf ~/Documents"
much faster that way.

But I know that I am old and odd duck who uses a curses-based MUA.[1]

By all means, make a stronger case for the threat this suggested exploit
poses than the reporter did.  I'm not wedded to the spooling feature
remaining on available in safer mode.  But (1) I don't want to pull it
behind that gate lacking a _persuasive_ case to do so; and (2) I invite
the reader to look over groff_font(5) and behold my improvements^W^W^W
consider similar vectors that other directives might make possible.

Regards,
Branden

[1] Or maybe (Neo)mutt is still using S-Lang, wretchedly.  I dare not
    look.
signature.asc (application/pgp-signature, 833 B)