> 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
