Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 16 Jul 2008 11:35:01 +0100
From: "Jan Minář" <>
To: "Tomas Hoger" <>
	"Jonathan Smith" <>,, 
	"Bram Moolenaar" <>, 
	"Charles E Campbell, Jr" <>
Subject: Re: Re: More arbitrary code executions in Netrw version 125, Vim 7.2a.10

On Tue, Jul 15, 2008 at 4:43 PM, Tomas Hoger <> wrote:
> On Sun, 13 Jul 2008 01:35:42 +0100 "Jan Minář" <>
> wrote:
>> Thanks for CCing me.  Thomas's observations are right.
> No problem.  Your inputs are really appreciated, as you obviously spent
> a lot of time on researching those issues.
>> > CVE-2008-2712 description does not mention tar.vim issue.  It is
>> > described in, but its test does not seem to be run when
>> > doing make test for the top-most Makefile in the first test suite.
>> That's correct, I omitted the test from the top-most Makefile by
>> mistake.
> I believe this is already corrected in your updated test suite:
> On Thu, 10 Jul 2008 18:55:46 +0200 Tomas Hoger <>
> wrote:
>> Jonathan, did new netrw tests work for you?  With which vim version?
>> They all failed for me with vim 7.1.245 / netrw 109.
> Regarding those new netrw issues:
> - Issues 1 (netrw.v2) and 2 (netrw.v3) (for mz and mc commands) does not
> seem to affect any stable version of vim.  Support for those commands
> was only added after vim 7.1 and should only affect 7.2 alpha (and
> possibly also beta, which was released this week iirc).

As has been pointed out elsewhere, the runtime (netrw.vim being part
of it) updates are independently of the patches -- at the time of the
release of the first advisory, the contemporary runtime had some of
the vulnerabilities fixed, for example.  I'm not sure if the changes
are kept track of outside of the point releases.  Since distributions
generally pick whatever is current at the time of the release, is it
meaningful to say x.y is vulnerable, and x.z isn't?  The runtime files
are versioned and dated, so for example the first version of ftp.vim
not vulnerable is version 21 of 2008-07-12.

> Steven, are you going to split / de-dupe CVE ids based on this
> information and the information in my post in other thread:
> ?

You people are obviously more versed in assigning CVEs, so let me
submit very humbly:  The overall issue is that up until recently Vim
script did not provide any means of quoting metacharacters.  At the
time of the first advisory, there were close to a thousand ``execute''
statements.   The particular vulnerabilities detailed in the
advisories are examples of a more widespread tendency in the Vim code.
 Should there be a separate CVE for the overall issue, alongside CVEs
for the particular vulnerabilities?

From what I could find on the web this morning, I'm not sure whether
this is the way CVEs are supposed to work.  There will surely be more
confirmed vulnerabilities, and it would be nice to be able to point to
a CVE number and say: ``This is one of the vulnerabilities under

I hope I've helped the discussion a bit.

Jan Minar.

PS: The buffer overflow is interesting -- thanks!

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.