Short answer: In many situations, Vim is vulnerable to this kind of attack (when pasting text in Insert mode).
Proof of concept
Using the linked article as a starting point, I was able to quickly create a web page with the following code, using HTML span elements and CSS to hide the middle part of the text so that only
ls -la is visible to the casual viewer (not viewing the source). Note: the
^[ is the Escape character and the
^M is the carriage return character. Stack Exchange sanitises user input and protects against hiding of content using CSS so I’ve uploaded the proof of concept.
ls ^[:echom "This could be a silent command."^Mi -la
If you were in Insert mode and pasted this text into terminal Vim (with some qualifiers, see below) you would see
ls -la but if you run the
:messages command, you can see the results of the hidden Vim command.
To defend against this attack it’s best to stay in Normal mode and to paste using
"+p. In Normal mode, when putting text from a register, the full text (including the hidden part) is pasted. This same doesn’t happen in Insert mode (even if
:set paste) has been set.
Bracketed paste mode
Recent versions of Vim support bracketed paste mode that mitigate this type of copy-paste attack. Sato Katsura has clarified that “Support for bracketed paste appeared in Vim 8.0.210, and was most recently fixed in version 8.0.303 (released on 2nd February 2017)”.
Note: As I understand it, versions of Vim with support for bracketed paste mode should protect you when pasting using Ctrl–Shift–V (most GNU/Linux desktop environments), Ctrl–V (MS Windows), Command–V (Mac OS X), Shift–Insert or a mouse middle-click.
I did some testing from a Lubuntu 16.04 desktop machine later but my results were confusing and inconclusive. I’ve since realised that this is because I always use GNU screen but it turns out that screen filters the escape sequence used to enable/disable the bracketed paste mode (there is a patch but it looks like it was submitted at a time when the project was not being actively maintained). In my testing, the proof of concept always works when running Vim via GNU screen, regardless of whether Vim or the terminal emulator support bracketed paste mode.
Further testing would be useful but, so far, I found that support for bracketed paste mode by the terminal emulator block my Proof of Concept – as long as GNU screen isn’t blocking the relevant escape sequences. However, user nneonneo reports that careful crafting of escape sequences may be used to exit bracketed paste mode.
Note that even with an up-to-date version of Vim, the Proof of Concept always works if the user pastes from the
* register while in Insert mode by typing (Ctrl–R*). This also applies to GVim which can differentiate between typed and pasted input. In this case, Vim leaves it to the user to trust the contents of their register contents. So don’t ever use this method when pasting from an untrusted source (it’s something I often do – but I’ve now started training myself not to).
- What you see is not what you copy (from 2009, first mention of this kind of exploit that I found)
- How can I protect myself from this kind of clipboard abuse?
- Recent discussion on vim_dev mailing list (Jan 2017)
Use Normal mode when pasting text (from the
… or use Emacs. I hear it’s a decent operating system. 🙂
If you’re using the X11 clipboard feature, or a platform-specific equivalent, and you use middle-button paste with mouse support enabled or a vim paste command and not any terminal paste command (shift-middle-button or whatever shortcuts the terminal offers) then you might be safe.
If not, then if you have a terminal emulator that supports bracketed-paste mode, and you’ve enabled that in your terminal and in vim, and that terminal emulator implements protection against the injection of the escape sequence that ends bracketed-paste mode, then you might be safe.
If not, then you might be vulnerable to the attack described here.