6 update short answer so it's more correct
source | link

Short answer: In many situations, Vim is vulnerable to this kind of attack (whilewhen pasting text in Insert mode).

Short answer: Vim is vulnerable to this kind of attack (while in Insert mode).

Short answer: In many situations, Vim is vulnerable to this kind of attack (when pasting text in Insert mode).

5 add link referenced by Gilles' comment
source | link
4 added more info, particularly with regard to GNU screen
source | link

Using the linked article as a starting point, I couldwas 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. Since Stack Exchange sanitises user input and protects against this sort of malicious hiding of content using CSS, so I’ve quickly created and uploaded athe proof of concept.

If you were already 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.

I’ve tried this with both Vim 7.4 on a Linux terminal and GVim 8 (with patches 1-2) on Windows and in both cases, the attack was successful. There may be other attack vectors but this was something I quickly came up with.

Of course, the best safeguard is to upgrade to a recent versionRecent versions of Vim support bracketed paste mode that protects againstmitigate 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.

Testing

I’ll testI did some testing from a GNU/LinuxLubuntu 16.04 desktop machine later on but my results were confusing and inconclusive. I’ve noticedsince realised that running Vim 8.0this 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 (with patches 1-329) in Cygwin’s mintty terminalthere is still vulnerable to Insert-mode pasting when usinga Shift-Insertpatch but it looks like it was submitted at a time when the project was not being actively maintained). Also 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, you’re still vulnerablethe Proof of Concept always works if you pastethe 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).

Related links

Use Normal mode when pasting text (from the + or * registers).

… or use Emacs. I hear it’s a decent operating system. :)

I could 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. Since Stack Exchange protects against this sort of malicious hiding of CSS, I’ve quickly created and uploaded a proof of concept.

If you were already in Insert mode and pasted this text into Vim, you would see ls -la but if you run the :messages command, you can see the results of the hidden Vim command.

I’ve tried this with both Vim 7.4 on a Linux terminal and GVim 8 (with patches 1-2) on Windows and in both cases, the attack was successful. There may be other attack vectors but this was something I quickly came up with.

Of course, the best safeguard is to upgrade to a recent version that protects against this 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-V (MS Windows), Command-V (Mac OS X), Shift-Insert or a mouse middle-click.

I’ll test from a GNU/Linux desktop machine later on but I’ve noticed that running Vim 8.0 (with patches 1-329) in Cygwin’s mintty terminal is still vulnerable to Insert-mode pasting when using Shift-Insert. Also, even with an up-to-date version of Vim, you’re still vulnerable if you paste from the * register while in Insert mode by typing (Ctrl-R*).

Use Normal mode when pasting text.

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.

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.

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.

Testing

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).

Related links

Use Normal mode when pasting text (from the + or * registers).

… or use Emacs. I hear it’s a decent operating system. :)

3 further clarification
source | link
2 add proof of concept
source | link
1
source | link