[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080716164223.598f1ede@redhat.com>
Date: Wed, 16 Jul 2008 16:42:23 +0200
From: Tomas Hoger <thoger@...hat.com>
To: oss-security@...ts.openwall.com
Cc: rdancer@...ncer.org, "Jonathan Smith" <smithj@...ethemallocs.com>,
coley@...us.mitre.org, "Bram Moolenaar" <Bram@...lenaar.net>,
"Charles E
Campbell, Jr" <drchip@...pbellfamily.biz>
Subject: Re: Re: More arbitrary code executions in Netrw
version 125, Vim 7.2a.10
On Wed, 16 Jul 2008 11:35:01 +0100 "Jan Minář" <rdancer@...ncer.org>
wrote:
> 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.
I've checked how vim is packages in multiple Linux distros, they mostly
seem to be consist of:
- vim{,-extra,-lang}-X.Y.tar.gz
- official patches up to X.Y.Z, where Z closely corresponds to distro
release date
- distro-specific patches
vim-X.Y contains most of the runtime and I believe most of the fixes
even to runtime gets to distros either via official patches, or via new
runtime as bundled with next vim X.(Y+1). So saying that issue is
fixed via (official upstream) patch X.Y.Z seems to make sense in
many cases. Having first affected / first fixed version information per
plugin is helpful too.
Btw, ftp.vim?
> > Steven, are you going to split / de-dupe CVE ids based on this
> > information and the information in my post in other thread:
> >
> > http://www.openwall.com/lists/oss-security/2008/07/15/2 ?
>
> You people are obviously more versed in assigning CVEs
Ouch... but that's probably what "we" deserve ;). Getting CVE naming
right is part of the process of handling security vulnerabilities.
Having some issue clearly mapped to id (and possibly also fix) can help
dealing with the issue, especially if some issue is revisited after
some time.
> 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.
Based on your research, do you believe that all / most of them can
really be exploited to perform some harmful actions just by user
opening some file with odd file name?
> 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?
I'm not aware of any example of such generic umbrella CVE and I believe
"tendency" it not a good candidate for CVE id, as CVE should map to
particular vulnerability. Though there are few special cases / CVEs,
so Steven may correct me in this.
> 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
> CVE-2008-xxxx''?
That won't work from CVE point of view. There's set of currently know
exploitation vectors, that got some id assigned. Sooner or later,
upstream and vendors will release updated packages, claiming particular
id is addressed. Adding new issues to the same id later can only
result in further confusion, leaving no good way to identify which
package version actually addressed issues covered by given id.
> I hope I've helped the discussion a bit.
Of course, it is really appreciated!
--
Tomas Hoger / Red Hat Security Response Team
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.
