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

[G. Branden Robinson]

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

signature.asc
Description: PGP signature