Re: Re: More arbitrary code executions in Netrw version 125, Vim 7.2a.10

[Tomas Hoger <thoger () redhat com>]

On Sun, 13 Jul 2008 01:35:42 +0100 "Jan Minář" <rdancer () rdancer org>
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 3.4.2.3, 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:
http://www.rdancer.org/vulnerablevim.2008-07-13.tar.bz2

On Thu, 10 Jul 2008 18:55:46 +0200 Tomas Hoger <thoger () redhat com>
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).

- Issue 3 (netrw.v4) affects netrw versions of netrw as shipped with
vim 7.0 and 7.1.  This problem does not seem to affect explorer.vim
used by vim 6.x.

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 ?

Sounds like this may be a good split, but I'm afraid I'll get stoned
for causing another CVE headache mess:
- CVE-2008-2712 - first advisory; xpm, filetype, gzip tests; affects
vim 6.0+, possibly older (not checked)
- CVE-new1 - first + second advisory; netrw and netrw.v4 tests; vim 7.0+
- CVE-new2 - first advisory; netrw test; explorer.vim on vim 6.x,
possibly older
- merged CVE-2008-3074 and CVE-2008-3075 - first + second advisroy;
tarplugin* and zipplugin tests; vim 7.0+
- CVE-new3 - second advisory; netrw.v2 and netrw.v3 tests; vim 7.2a+

Of course, this split takes into account first affected version, not
when the issue got / will get fixed.  I believe not all issues are
already fixed upstream.  Bram, feel free to correct me if I'm wrong.

Additionally, netrw.v3 uncovered one old bug affecting some 6.2 and 6.3
vim versions.  On affected versions, it triggers heap buffer overflow,
when vim is used to open file or directory with specially crafted name.

The problem is in the mch_expand_wildcards() in os_unix.c.  Problem was
introduced in 6.2.429:
  http://vim.cvs.sourceforge.net/vim/vim/src/os_unix.c?view=log#rev1.104
  ftp://ftp.vim.org/pub/vim/patches/6.2.429

After applying this patch, following occurs:
- vim tries to run external command to perform shell expansion, to
calculate a buffer size needed to store this command, following code is
used:

  /* "unset nonomatch; print -N >" plus two is 29 */
  len = STRLEN(tempname) + 29;
  for (i = 0; i < num_pat; ++i)       /* count the length of the patterns */
      len += STRLEN(pat[i]) + 3;      /* add space and two quotes */
  command = alloc(len);

(i.e. expected command is: <some fixed length prefix> <space> <quote>
<pattern from file/directory name> <quote>, possibly with multiple
patterns).

However, later in the code, more complex quoting is used, which quotes
being added around spaces and 's, so patterns with lots of spaces can
easily trigger command buffer overflow:

    if (vim_strchr((char_u *)" '", pat[i][j]) != NULL)
    {
        *p++ = '"';
        while (pat[i][j] != NUL
                && vim_strchr((char_u *)" '", pat[i][j]) != NULL)
            *p++ = pat[i][j++];
        *p++ = '"';
    }
    else
        *p++ = pat[i][j++];

Issue was addressed upstream in:
  http://vim.cvs.sourceforge.net/vim/vim/src/os_unix.c?view=log#rev1.111
  ftp://ftp.vim.org/pub/vim/patches/6.3/6.3.059

Memory requirement computation phase was updated to take this quoting
mechanism into account.  This was further re-written for vim 7.0 in:
  http://vim.cvs.sourceforge.net/vim/vim7/src/os_unix.c?r1=1.49&r2=1.50

Steven, can you please allocate an id for this heap corruption
affecting 6.2.429 - 6.3.059?  Thanks!

-- 
Tomas Hoger / Red Hat Security Response Team