Re: Groff should not permit ANSI escapes using \N'27'

[John Gardner]

>
> I don't think they're stripped for security reasons, but because groff
> repurposes chunks of the control-character code space for its own uses.


Oh. Erh, I didn't know that... I kind of assumed that, being the escape
character, it was filtered for the reasons I described earlier.

Is this really our problem to solve?


Nope. Pretend this thread never happened.


On Fri, 7 Aug 2020 at 00:29, G. Branden Robinson <
g.branden.robinson@gmail.com> wrote:

> At 2020-07-28T00:26:49+1000, John Gardner wrote:
> > Hi folks,
> >
> > Raw escape characters (U+001B) get stripped from source-code during
> > formatting, but inserting one is still possible using \N'27':
>
> I don't think they're stripped for security reasons, but because groff
> repurposes chunks of the control-character code space for its own uses.
>
> I've updated our documentation recently with respect to this issue.
>
> https://git.savannah.gnu.org/cgit/groff.git/commit/
>         ?id=6353ceb8b92e8e9fe927e5c93ceef1be6f54067c
>
> > \N'27'[4mI don't remember underlining this.\N'27'[0m
> >
> > This has potential security implications for people using `less -R`
> > (and can still mess up terminal output for those who don't).
>
> I suppose this is possible but you're probably not casting your net wide
> enough.  We'd also have to block CSI 0x9B and OSC 0x9D as well.
>
> xterm's ctlseqs.ms document should probably be reviewed.
>
> But consider this too.
>
> People can also have groff documents that deplete the paper trays:
>
> .while 1 .bp
>
> Or, even worse, which recreate the "black fax" DoS attack of yesteryear.
>
> How shall we guard against this sort of problem in documents destined
> for physical printing?
>
> For some years, xterm has had runtime-configurable options to suppress
> controls and information leaks, and the really dangerous ones default
> off.
>
> Is this really our problem to solve?
>
> Regards,
> Branden
>