Bugzilla Bug 238120

CVE-2008-4101 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-4101):
  Vim 3.0 through 7.x before 7.2.010 does not properly escape
  characters, which allows user-assisted attackers to (1) execute
  arbitrary shell commands by entering a K keystroke on a line that
  contains a ";" (semicolon) followed by a command, or execute
  arbitrary Ex commands by entering an argument after a (2) "Ctrl-]"
  (control close-square-bracket) or (3) "g]" (g close-square-bracket)
  keystroke sequence, a different issue than CVE-2008-2712.

I am not able to reproduce this issue, vim herd?

Steps to reproduce:

Open a new file in vim.
Type in http://www.google.co.uk/search?q=&xclock&.
Press V (capital), thereby selecting the whole line in visual mode.
Press K (capital), thereby looking up the selection.

As a result, xclock is launched.

{gvim,vim,vim-core}-7.2.021 are in CVS.

Given that I'm running 7.2.021 and am still able to reproduce it as described
in comment #2, I assume not all issues are fixed?

(In reply to comment #4)
> Given that I'm running 7.2.021 and am still able to reproduce it as described
> in comment #2, I assume not all issues are fixed?
> 
That doesn't surprise me much. There might be something I'm missing about the
way vim is built
in gentoo, but it looks like the fix (patch 7.2.010) is never applied. Not only
because I can't seem
to find it anywhere among the patches that actually are applied, but also
because I can happily cd
to $S and apply the patch myself.

ping?

I did some research - NONE of the patches were being applied in vim-7.2.021 -
It was exactly equivalent to vim-7.2

I've just checked in vim-core-7.2.108, vim-7.2.108, and gvim-7.2.108, which
apply all applicable patches, and I have verified that this bug in particular
is fixed.

Let's give them some time to settle out, then we can stabilize.

What's a bit strange is:

I'd except S-K to just
 (1) show a manpage if there is one for whatever i selected
 (2) show an error message or simply do nothing if (1) is not the case.

Now, with 7.2.108 (and thus, the .21 patch), xclock is no longer opened when I
select "http://www.google.co.uk/search?q=&xclock&" (see also comment #2), which
is good. However I still do get this:

  http://www.google.co.uk/search?q=&xclock&: No such file or directory
  No manual entry for http://www.google.co.uk/search?q=&xclock&

The latter is what man(1) tells me. The former is what makes me scratch my
head. Let me modify this a bit:

Type in "/usr/bin/xclock", select everything using S-V and press S-K to open
the manpage. What happens (at least for me), is that /usr/bin/xclock (the
binary) is opened. This is harmless (I suppose) because the binary is not run
but only viewed (like :r). Still there's no reason for that to happen, is
there? (Of course I could've gone with anything, no reason to choose a binary
here. /etc/passwd works just as well).

(In reply to comment #8)
> Type in "/usr/bin/xclock", select everything using S-V and press S-K to open
> the manpage. What happens (at least for me), is that /usr/bin/xclock (the
> binary) is opened. This is harmless (I suppose) because the binary is not run
> but only viewed (like :r). Still there's no reason for that to happen, is
> there? (Of course I could've gone with anything, no reason to choose a binary
> here. /etc/passwd works just as well).

Well, according to ':help K', this all depends on the value you have for ':set
keywordprg'  Mine apparently defaults to 'man -s', which, after some 'special'
processing regarding the '-s' flag, means that whatever word is under the
cursor is passed to 'man' If it's 'strcpy', you get:

man strcpy

Which obviously works as expected.

If it's '/etc/passwd', it just passes this right to man, like this:

man /etc/passwd

And this ends up running /etc/passwd through whatever troff formatter man uses
these days and showing it in your pager.

This isn't a bug, it's just the way man works... Try it from your shell.

From 'man(1)':

... However, if name contains  a  slash  (/)  then  man interprets  it  as a
file specification, so that you can do man ./foo.5 or even man
/cd/foo/bar.1.gz.