Thank you, gentlemen. I had reached similar conclusions. At 2026-05-26T01:31:44-0300, Sebastien Peterson-Boudreau wrote: > Maybe I'm doing something wrong but I'm not even able to reproduce the > example Proof of Concept. The code in question does look a bit fishy > for command injection, but without a working example, my knowledge of > the inner-workings of groff is too limited to assess the plausibility. > > fwiw, the writeup does _reek_ of that overconfident, doomsaying, LLM > tone...
Yeah. The botching of the Subject line seemed like another giveaway. 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. As far as polluting a multi-user system you would > need root access to /usr/(local)/ share/groff to alter the DESC file, > so if you already have root access all bets are off anyway. If you > are installing groff other than from the FSF site then you are on your > own. 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". Well, _yeah_. That's what a shell is _for_. > It would be an improvement if the value of "printer" was validated in > some way if the -l flag is given. I thought about this for a while. Validated for what? Semicolons and/or ampersands? In the scenario presented by the report, the attacker can already create files on the user's system, thus the "DESC" file vector. And if they can do that, they can name as the "print" command a shell script that reads standard input and writes to standard output. To add validation or restriction logic, I need to hear a case that we'll actually be buying something with it. I'm not presuming there _is_ no case, but so far my imagination has failed me in coming up with one. At 2026-05-26T17:24:39-0700, Collin Funk wrote: > It is pretty low severity, if even a security issue. One should expect > 'groff' to execute arbitrary commands based on the DESC file, as it is > documented to do so [1]. Right. > I suggest not trying to validate the directives, which is bound to be > a headache and just using posix_spawn or fork + exec. If that is > possible. While I like the idea of using Bruno's "new" (relative to groff) support for posix_spawn() in gnulib, and he and I have mooted the issue before,[A] I'm a little leery of screwing with this aspect of the code unless I can establish a review loop with Eli Zaretskii, who seems to be the only contributor for many years to groff's Windows support, and Windows is the only non-POSIX platform for which I have any evidence of any groff release being circulated on the Web in the past decade or so. For the time being, I'm inclined to disregard the report for the foregoing reasons. I handled another recent report differently.[B] > [1] > https://www.gnu.org/software/groff/manual/groff.html.node/DESC-File-Format.html Regards, Branden [A] https://lists.gnu.org/archive/html/groff/2023-04/msg00163.html Gosh, that was 3 years ago... [B] https://savannah.gnu.org/bugs/?67899
signature.asc
Description: PGP signature
