At 2023-08-01T13:38:55+0200, Leah Neukirchen wrote:
> > I got to wondering, based on the sendmail discussions, how many
> > shell escapes have appeared over the years?
> >
> > uucp
> > sendmail
> > xdvi : "The "allowShell" option enables the shell escape in PostScript specials"
> 
> From the top of my head, where it can be disabled:
> 
> ghostscript (see above)
> tex (write18)
> ed/ex/vi
> nethack

And the *roffs of course.  nroff/troff/groff, with the `sy` (system(3))
and `pi` (popen(3)) requests.  pic(1) as well ("sh").

groff has, since version 1.12 in 1999, disabled these features by
default; the '-U' ("unsafe") command-line option reënables them.  It
added some additional unsafe requests for arbitrary stream I/O, `open`,
`opena` (open with append), and `pso` (`so` for pipeline output).

I recently learned of a limitation in the way AT&T and GNU *roffs, at
least, construct the string `sy` passes passes to system(3), which makes
certain things impossible.  Unfortunately it forecloses useful
applications, not any particularly malicious ones.

    There is a problem with trying to embed true newlines into the
    arguments of a `sy` request.  The C++ function that GNU troff uses
    to assemble the command string (character by character) _does not
    recognize C/C++ string literal escape sequences_.  This means that
    you _cannot_ embed "\n" in `sy`'s arguments and have it survive, as
    a newline character, into the command string passed to the standard
    C library's system(3) function.  ("A\nB" gets encoded as 'A', '\\',
    'n', 'B', not 'A', '\n', 'B'.) Unfortunately, this appears to be
    AT&T troff-compatible behavior.  But it means that you _cannot_
    portably construct multi-line replacement text for sed's 's'
    command.  (Other sed commands like 'a', 'c', and 'i' will be
    similarly affected.)  See Savannah #64071.

AT&T troff obviously wasn't written in C++, so this would appear to be
an instance of independent oversight.  (Where James Clark had gripes
about AT&T troff behavior, he left them in source code comments.)

I aim to fix this.  If I can write an arbitrary shell command, then I
darn well ought to be able to embed an arbitrary sed script in that
shell command (without needing a GNU sed extension to embed newlines).

Regards,
Branden