bug#66390: `man' allows to inject arbitrary shell code

[Max Nikulin]

On 08/10/2023 01:26, Eli Zaretskii wrote:
> So the problem _is_ with the shell?  If so, the best way of avoiding
> these problems is not invoke 'man' via the shell, but via call-process
> and its ilk instead.

It will be great if it is possible to avoid shell in the middle. However
- man.el uses pipes with sed and awk to post-process output of man 
executable.
- if support of remote man files is considered then it is even more hard 
to avoid shell. SSH assumes shell commands.

I had in mind using at least `shell-quote-argument'.

The issues of sanitizing outputs in callers
- If there was a safe function in man.el then callers code would be more 
simple, so it would be less probable to introduce bugs in such code.
- behavior of the `man' emacs command is *underspecified*, so it is hard 
to provide safe argument for it. Some parenthesis are allowed as in 
"man(1)" others may be interpreted by shell.
- `shell-quote-argument' in callers would rely on man.el implementation 
details at best or may even lead to undefined behavior since I see have 
no way to bypass some processing of the argument of the `man' emacs command.

Execution a part of `man' emacs command argument by shell is a surprise 
to the user any case. Ideally elisp code should prevent it and man.el 
should emit an error.

Attempts to call of `man' from other packages is an open door for 
security vulnerabilities.

I was really surprised when I noticed that various Linux distributions 
patched and updated emacs even in stable releases in response to 
https://security-tracker.debian.org/tracker/CVE-2023-28617 Formally the 
score of this CVE was high.