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.
Added to existing GLSA request.
This issue has been fixed since Jul 26, 2009. No GLSA will be issued.
