<<< Date Index >>>     <<< Thread Index >>>

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