RE: Arbitrary Code Execution in Commands: K, Control-], g]
> From: rdancer@xxxxxxxxx [mailto:rdancer@xxxxxxxxx] On Behalf
> Of Jan Minár
> Sent: Friday, 22 August, 2008 10:26
> To: bugs@xxxxxxx; vim-dev@xxxxxxx;
> full-disclosure@xxxxxxxxxxxxxxxxx; bugtraq@xxxxxxxxxxxxxxxxx
> Subject: Vim: Arbitrary Code Execution in Commands: K, Control-], g]
>
> Vim: Arbitrary Code Execution in Commands: K, Control-], g]
This report greatly overstates the danger of this bug. It's worth reading the
discussion from the Vim Dev list (Minár's [2] below).
> 3.1. Keyword Lookup -- The ``K'' Command
>
> 3.1.1. Shell Commands and Ex Commands
>
> Because the string passed to the shell for execution is not
> sanitized, it is possible to specify arbitrary shell commands
> where Vim expects an argument for the keyword program. Same
> applies to arbitrary Ex commands.
The K command is designed to execute an arbitrary program. The user can set the
program by setting the keywordprg option. Minár's exploits require setting vim
options to implausible values, either using a modeline (which no sensible user
ever allows on untrustworthy files, and no truly security-conscious user
enables at all) or monumental user stupidity. Given that, why not simply set
keywordprg? Or do anything else that a modeline allows?
> 3.1.2. Keyword Program Command Line Switches
>
> It is possible to specify command line switches for the
> keyword program in place of the argument. The gravity of
> this vulnerability depends on the keyword program selected.
> GNU man, the default keyword program in many installations,
> supports for example the ``--pager'' option (cf.
> the GNU man(1) manual page). This allows arbitrary command execution.
As does setting PAGER in the environment before vim starts, which is an equally
plausible attack.
Schmidt did accidentally discover an issue with unescaped characters and the K
command - specifically with Visual-K and an unconventional setting of
keywordprg, used in a manner for which it was not intended (selecting a URL and
using K to pass it to a browser). See Minár's [1]. So it's not impossible for
someone to encounter this bug while operating in a manner they think is
sensible.
But very few users will create the necessary conditions, so the attack surface
is vanishingly small; and users who do that sort of thing with untrustworthy
data are going to shoot themselves in the foot sooner or later. No vim required.
It'd be much better to focus on vim security issues that have some chance of
exploitation, like the netrw problems that Minár recently documented. This sort
of thing is just noise.
> [1] Ben Schmidt discovered this vulnerability in:
> Message-Id: <48AB91B3.9000709@xxxxxxxxxxxx>
> http://groups.google.com/group/vim_dev/msg/6ad2d5b50a96668e
>
> [2]
> http://groups.google.com/group/vim_dev/browse_thread/thread/14
> 34d0812b5c817e/6ad2d5b50a96668e
>
> [3] http://groups.google.com/group/vim_dev/msg/dd32ad3a84f36bb2
--
Michael Wojcik
Principal Software Systems Developer, Micro Focus