10 ms·
Vim/Neovim Arbitrary Code Execution via Modelines
- tombert 7y agoWell crap, now I have yet another reason to lose sleep tonight. I always thought Vim and text-files were safe. I do find something endlessly interesting in these kinds of vulnerabilities, for no other reason than the fact that I can appreciate the hunt for them. I wouldn't really think to look at Vim as an attack vector, and even if I did, I wouldn't even know where to start.
- gowld 7y agoThe article cites security bugs in bugs from 2016 and 2002
- cjbprime 7y agoCheck this one out, then: http://www.h-online.com/security/news/item/Xterm-terminal-emulator-executes-injected-commands-739557.html http://www.h-online.com/security/news/item/Xterm-terminal-em...
- cyphar 7y agoGiven that most administrators use vim to edit everything in the system and often open random files, I would think vim is the most obvious thing to attack (just like printers in corporate networks). Just do "set nomodeline" and move on. I've had it disabled for the past ~10 years because of previous CVEs like this (such as CVE-2007-2438).
- lloeki 7y agoor use https://github.com/ciaranm/securemodelines https://github.com/ciaranm/securemodelines like I did for the past aeon
- AzzieElbab 7y agoNo !!! Not my vim
- deleted 7y ago[deleted]
- tluyben2 7y agoIn which case would I open a file with vim like that? Or can it be hidden in innocent looking files? I always first cat a file. And never heard of modeline even though using vim for over 20 years.
- paxswill 7y agoThe second PoC hides the modeline when printed with `cat`.
- tluyben2 7y agoSorry, missed that one, thanks for pointing out.
- panpanna 7y agoThey say there is no "i" in "denial". Disclaimer: I use emacs.
- marshray 7y agoWhen you cat a file, this is what you are allowing it to do to your console/terminal: http://man7.org/linux/man-pages/man4/console_codes.4.html http://man7.org/linux/man-pages/man4/console_codes.4.html
- Pmop 7y agoI guess we have a winner for Editor Wars.
- NegativeLatency 7y agoEmacs has similar functionality https://www.gnu.org/software/emacs/manual/html_node/emacs/Specifying-File-Variables.html https://www.gnu.org/software/emacs/manual/html_node/emacs/Sp...
- Pmop 7y agoIs there any CVE on it published already? It'd be very funny if yes or if someone publishes one following Vim's.
- projektfu 7y agoYep. Search the text for "variable" https://www.cvedetails.com/vulnerability-list.php?vendor_id=72&product_id=741&version_id=0&page=1&hasexp=0&opdos=0&opec=0&opov=0&opcsrf=0&opgpriv=0&opsqli=0&opxss=0&opdirt=0&opmemc=0&ophttprs=0&opbyp=0&opfileinc=0&opginf=0&cvssscoremin=0&cvssscoremax=0&year=0&cweid=0&order=1&trc=21&sha=001be71c19fab6171046f0b812da8d1378e05f02 https://www.cvedetails.com/vulnerability-list.php?vendor_id=...
- nonbirithm 7y agoThe default behavior on Emacs is to warn you that file-local variables can be unsafe and prompt you to execute them. However I developed the habit of mostly ignoring it since they're usually in my own files. https://www.gnu.org/software/emacs/manual/html_node/emacs/Safe-File-Variables.html https://www.gnu.org/software/emacs/manual/html_node/emacs/Sa...
- NikkiA 7y agoThe scary part for me (albeit that I'm an emacs user not really a vim user) here is that the modeline string is hidden from the victim in their vim window, so not only have they enabled the RCE they aren't aware of it. I'm not sure if emacs file-local variables can be exploited in the same way (they probably can but I'm just unaware of it)
- jalgos_eminator 7y agoVery interesting exploit. Makes me feel good that I disable modelines because my company always sets columns=96, however I usually open multiple files with :vsp and I have to manually change the columns to what my terminal actually is. I would be interested to hear the historical reason for having such generic modeline execution in the first place. It seems a little out of place in text file editing.
- gbrown_ 7y ago> Makes me feel good that I disable modelines because my company always sets columns=96 Your company places this as a modeline in all its source files? If so why does your place of work enforce modelines in its source?
- jalgos_eminator 7y agoThey don't "enforce" it, but all the code written by the two largest contributors always has it. Its a startup, so those two contributors wrote the majority of the codebase.
- dmix 7y agoYou mean they include editor configuration in all of their source code files? Not just some special cases?
- jalgos_eminator 7y ago# vim:set columns=96 expandtab nocindent nosmartindent ff=unix: This is in basically every source code file just below the shebang.
- dmix 7y agoI've never seen anyone do this. There are so many better solutions to this problem and it's a heavy-handed/messy solution that is difficult to change/maintain. I'd push back on this hard if I was told to do it.
- gbrown_ 7y agoI have never understood the appeal of modelines. Why on earth would you put editor specific configuration inline with the file you are editing? Thankfully I've had 'set nomodeline' in my config ever since I found out about this insane option.
- eikenberry 7y agoI've found them useful for settings the filetype when you don't have the mime-suffix or other easy method to identify it. But that's about it.
- gbrown_ 7y agoPresumably that's for something only you work on? Do others not find it confusing as to what that line is doing in the file?
- anowlcalledjosh 7y agoPresumably it's no more confusing than, say, a shebang is for Windows users.
- gbrown_ 7y agoAn interpreter directive is far more common than a piece of configuration specific to an editor. It also serves a practical purpose on *nix style systems whereas editor configuration is a matter of preference.
- eikenberry 7y agoNormal use case, yes, this is only stuff I work on. When collaborating you must assume heterogeneous development environments which make this kind of thing useless.
- tom_ 7y agoI use them in Emacs occasionally. It's handy for stuff with ambiguous names. Makefiles (which dialect?), whatever.pl (Perl? Prolog?), whatever.asm/whatever.s (which architecture? Which assembler?), etc. Also comes in handy for working with files that have an incorrect extension, for whatever reason, or different formatting from all the other files of that type that you work with. (Per-project formatting stuff can often by solved with .dir-locals.el, but not always.)
- deleted 7y ago[deleted]
- ploxiln 7y agoThis is a well known problem - thus the "securemodelines" plugin: https://github.com/ciaranm/securemodelines https://github.com/ciaranm/securemodelines
- Izkata 7y agoSeems so, Ubuntu's defaults (at least in 16.04) set nomodeline with a comment about security vulnerabilities.
- fatbird 7y agoIf you're heartbroken about this, it's only because you were too smug before.
- fatbird 7y agoBefore I go completely grey here, I'll clarify as a decades long user of vim/neovim: no software should be so near and dear to your heart that you get complacent about the risks it poses, most especially security risks. Heartbreak at this announcement means you were assuming it wasn't a vector for security weaknesses.
- cjhanks 7y agoWhich OS' are compiling `nc` with `-DGAPING_SECURITY_HOLE` ?
- cjhanks 7y agoJeez, what's with the down votes? Look at the netcat documentation, that's what the configuration option for "-e" is called. https://ps.uci.edu/~franklin/doc/netcat.html https://ps.uci.edu/~franklin/doc/netcat.html https://stackoverflow.com/questions/15351646/how-to-re-compile-netcat-with-options https://stackoverflow.com/questions/15351646/how-to-re-compi...
- nebulous1 7y agoThe -e option is pretty useful for security researchers, so it would be common enough for people trying the POC
- deathanatos 7y agoWhat's the gaping security hole there? My interpretation of the documentation is that -e PROG execs PROG with stdin/stdout set to the accepted socket. (I mean, it's possible to write a program that, if it receives any input on stdin, would rm -rf everything. But the error seems with the combination of the program and -e, and not -e? That is, -e isn't inherently dangerous? Or do we just not trust ourselves that much?)
- cyphar 7y ago-DGAPING_SECURITY_HOLE is how you have to compile nc in order to enable "-e" support. The gaping security hole is that it is literally RCE-as-a-feature -- yes, it's not as bad as "pass any text you get over this socket to a shell session" but it's still pretty bad.
- maxdamantus 7y agoI feel like security for CLI users is generally falling behind other systems. On Android and iOS, any application is supposedly running in its own sandbox, where it can't just randomly access files used by the rest of the system (including other applications). The web is obviously strongly based around a security model where a website ultimately can't do much in terms of information access (eg, a properly designed website's information is protected from other websites) .. as I understand it, this was not always the case (we're not using ActiveX anymore, right?). In the desktop space, this pattern is supposedly supported by Flatpak, and I think the macOS store (though I'm not sure about this—I haven't actually used either). Meanwhile, when a random developer decides to run `make` or `npm install` or `mvn install` or even `vim foo.txt`, they're essentially trusting their entire computer to whoever created the content in their working directory. Will there be some revolution at some point that encourages people to somehow isolate their commandline activities to different realms, thus limiting the scope of any attack like this?
- ajross 7y ago> any application is supposedly running in its own sandbox, But that fails for developers (which is more or less synonymous with "CLI users"). Development is all about data and fine grained tools, not apps. You check out a file with git, then edit it with vim, and build it with gcc, which pulls in headers generated with a python script, itself having been configured with, I dunno, cmake gadgetry. Where do you draw the boundaries here? I mean, you can draw a big circle around all your development activities. Products have been invented that do that. They're called "IDE's", and are sort of the metaphorical opposite of the command line tools we're discussing, and not really a solution to the people choosing to use this environment. Alternatively, you can view the whole development system as a sandbox. Do your work in a separate VM or docker instance, for example. Some people actually do that (in particular folks with windows desktops who need linux tooling will recognize this), and while it's not generally considered a security technique, it certainly could be.
- maxdamantus 7y ago> You check out a file with git, then edit it with vim, and build it with gcc, which pulls in headers generated with a python script, itself having been configured with, I dunno, cmake gadgetry. Where do you draw the boundaries here? None of this should not require access to things like my web browser, my ~/.config directory, some directory like ~/build/go containing an unrelated project. > They're called "IDE's" IDEs don't exist for security reasons, but I think you can at least use the existence of these things as evidence that there is a sensible way of scoping development activities. I imagine it wouldn't be a major hindrance if IDEs did provide this sandbox functionality, where you could still launch a shell within the IDE, and that shell would be in a mount/pid namespace controlled by the IDE. Personally, I want something that applies not just to development, but general computer use. If you go back 15 years, it was probably fairly typical for someone to expect to download an run an "EXE" file. Now the expectation is that a website or phone app is used instead, which has fewer security implications. Surely there must be some path for moving to something more secure when it comes to commandline usage.
- bch 7y agonvi nipped this in the bud from inception: modelines, modeline [off] Read the first and last few lines of each file for ex commands. This option will never be implemented.[0] [0] https://netbsd.gw.com/cgi-bin/man-cgi?vi+1.i386+NetBSD-8.0 https://netbsd.gw.com/cgi-bin/man-cgi?vi+1.i386+NetBSD-8.0
- hamburglar 7y agoMy system vimrc has: set modelines=0 and a comment referencing CVE-2007-2438, which was another sandbox escape via modelines. Seems prudent.
- bla3 7y agoIt's mildly interesting that the neovim patch for this [1] is just an import of the upstream vim patch [2], but with the test removed. 1: https://github.com/neovim/neovim/commit/4553fc5e https://github.com/neovim/neovim/commit/4553fc5e 2: https://github.com/vim/vim/commit/5357552 https://github.com/vim/vim/commit/5357552
- ryanar 7y agoI wonder if it is because neovim's testing is setup differently and they wanted to port the patch immediately rather than spend time which they might not have had at the moment to rewrite the test. I suppose the patch was tested upstream, though you would want the test in neovim to prevent a future regression.
- justinnhli 7y agoA different PR is still open, that presumably would include the test: https://github.com/neovim/neovim/pull/10052 https://github.com/neovim/neovim/pull/10052
- cyphar 7y agoI remember reading ~10 years ago that mode-lines were considered to be insecure (you are parsing arbitrary data as configuration options) and have always had them disabled in my .vimrc. I'm surprised they haven't been disabled by default (even in neovim). EDIT: I probably was reading about CVE-2007-2438, another mode-line based RCE attack.
- hannob 7y agoThis should be put into perspective: The default vimrc configuration file disables the modelines option and contains a warning that it is a security risk. I.e. this likely only affects a small number of users and the devs have done as much as they can about a risky feature: Off by default and whoever changes the option should know about the risks. Of course it's still a valid vulnerability and it's good that it's been found and fixed. But it's likely not a big deal.
- gfiorav 7y agoI'd like to note here that while the vim versions of OS distros get updated every now and then, Bram does a fantastic job of releasing multiple times per week and vim is easy to compile. I compile it every week (I use it as my IDE -- term buffers and all). Just in case someone here is a heavy user and is worried about this. https://github.com/vim/vim https://github.com/vim/vim
- isr 7y agoScratching my head a bit but ... isn't this old news (the underlying issue, not the github doc)? The modelines issue (this exact issue) was widely publicised well over a decade ago (long enough that I don't remember when). I vaguely recall it showing up in an early gentoo security alert (pre-2005?) which is how I became aware of it. How does this become a new security issue now?
- marshray 7y agoSimple: Modelines come from a time before we understood that ordinary user applications working with ordinary files needed to be engineered securely.
- isr 7y agoI think you missed my question :) I understand the security concerns (arbitrary code execution just by loading an arbitrary file into vim). My question was: this issue was caught, diagnosed, widely publicised and the configuration fix for it was widely deployed - nearly 15 (fifteen!) years ago. So why is it cropping up as a "new" security issue now?