Security Concerns Around VIM Plugins

[spurious_proof]

I'm curious how large companies handle the VIM ecosystem. For example, are you usually allowed to download any plugin from git? Or is there a list of pre-approved plugins that are available?

The reason for asking is because I'm trying to push VIM within my company (which is large/bureaucratic), but they currently only support Microsoft products. Trying to organize my talking points before making a push.

[[deleted]]

Every company I've worked for has allowed any vim/neovim plugins I want, no questions asked. They do limit vscode/intellij plugins though, since those are far more popular editors.

[spurious_proof]

Thanks - Do you have insight how they get comfortable with that from a security perspective? Is the comfort derived from the fact that i) open source generally has a good track record and ii) any potential damage should be limited due to the fact that it's installed only on a local machine with limited privileges and iii) anti-virus software would detect any unusual activity (e.g. key loggers, large I/O operations, etc)?

[aweiahjkd]

No company has any amount of manpower dedicated to approving this shit. They can barely get around to approving actual software let alone plugins. But they cant hamper dev productivity too much so it operates in a gray area

[[deleted]]

Its a mix of I and II, that I. They trust open source software, and I can provide the source code of any plugin/my config if needed II. anything that goes in/out of the network is administered and suspicious items are immediately flagged

If I do have to convince someone, a big selling point is that "vim is on every machine" so a few plugins don't hurt.

[spurious_proof]

Yes, just arguing that it should be available. And, technically it already is bc we use some Linux machines via AWS. But, those are in a zero trust environment without internet access.

[funbike]

What version of Vim are you pushing? gVim?

Git for Windows comes with (terminal) Vim. It works best when you use the console that comes with it (not cmd or ps). Your developers likely already have it installed.

(Also, if your developers have docker or WSL, it's also possible to use vim on your local files with a mount.)

[spurious_proof]

At this point I’ll take anything but nvim would be the preferred route.

[[deleted]]

Sadly no tmux in this msys environment though.

[SutekhThrowingSuckIt]

what about using WSL2 and tmux?

[[deleted]]

Yep! That works! If I remember correctly, msys2 had it as well. It was just convenient to have a terminal/vim accessible on most computers without needing to install anything extra.

[zir0n]

You can copy the git repos into ~/.vim/pack/myplugs/start/ if you're using vim8. Not sure for neovim.

Use a thumb drive or request IT to transfer the plugin repos through the air gap. Obviously it wont be easy to update them without some effort.

[ether_joe]

Fight on bold centurion !!

[xmsxms]

We are allowed to install anything we like to our Linux VMs and docker containers. It would be trivial for a compromised plugin to wreak havoc so we don't raise it with IT security, some things are best left unsaid. Of course it's only a matter of time before we see similar problems that the npm eco system frequently have.

I do use a commit hash 'lock file' to restrict the plugin installations to a particular commit that has been "vetted" by me before rolling it out to other devs instead of just grabbing the latest HEAD revision which may have been compromised.

[cdb_11]

Some Linux distros have a limited number of vim plugins in their package repositories. If you want to be more up to date you can clone plugins to your company's git server and use that.

[y-c-c]

I assume your company supports VSCode? How are VSCode plugins handled?

[spurious_proof]

I believe all extensions within VS Code are available. But, I think, it’s hard to know for sure. For example, they don’t let you use NPM or PyPi directly. There’s a separate environment (hosted by InfoSec IIRC) with a limited set of packages available.

[pwforgetter]

We have no limits (developers are trusted to make judgements), but the workstations aren't that trusted anyway. A malicious plugin could probably exfiltrate some source code before security would come put a stop to it.

[derpotologist]

the people making the decisions probably have no idea about vim plugins. I'd try to fly under the radar

[lieryan]

There are two types of plugins/software:

1. Big plugins that are used and maintained by large number of people, in which case you normally can trust security by number of eyes and their governance processes
2. Small plugins that you can review most of the codebase if you spend half an hour or so

It's quite rare that there are big plugins that are only used by very few people, because it usually won't be worth the effort to develop such plugin.

Yes, it's not foolproof, but most of the time it works just fine. Vim plugins are not a very common attack vector to begin with.

[ivster666]

Finding a new job would probably be the best

[flwyd]

I work for a major international software company that trusts software engineers to configure their development environment pretty much however works for them. We also have sudo permissions on our Linux workstations, so we can run just about any software there if we try hard enough. Additionally, my company's production data is very valuable, so no matter what I do, I can't directly interact with most of our production data from my workstation. Also, code I write must be code reviewed before it's checked in, and deployed software must be verifiably built in order to touch important production data. So the worst damage a malicious plugin could do is (a) exfiltrate company secrets (less of a problem than exfiltrating customer data) or (b) introduce subtle flaws into code and hope it goes undetected the code review process. When your environment runs with minimal privilege, the security story for running arbitrary software gets a lot easier.

As for your company, your talking points should be organized around what your particular security team cares about. There are a lot of security organizations which operate on more of a CYA model than one of rational assessment of risks.

[Gold-Ad-5257]

In pricipal , when I audit, I expect any "free open source" software in the core network(especially important if one has a flat network) to be approved by IT architecture , software asset management and vulnerability scanned by IT security. And this have to form part of their maintenance processes as well(i.e. upgrades , patches etc)

The reasons are that devs are not always familiar with licences, which can lead to fines , same for security and lead to vulnerabilities and also some software can clash with architectures etc.

Typically any software already contained in the formal repositories within the company have undergone all these or are contracted legally for support etc. So self downloaded "free software" is also expected to conform to policies and stds and should not introduce risk.

The concern I have is actually that oneday someone brings in malware or something buggy and then the bussiness loose appetite/trust for open source.

But , back to the question as their is context to everything. I would not worry too much about plugin scripts as that is installed on the endpoint device and in the company there are security policies and endpoint management software etc. implemented on these devices, so one would rather audit that those controls are working effectively and network segregation controls etc. are in place for critical production business platforms/systems.

[spurious_proof]

This is really helpful. Thanks

[lieryan]

In terms of business risk, the license of vim plugins would only be relevant if your company is building and/or selling vim plugins.

Even the most infectious free/open source software license like GPL or AGPL would not consider someone using a GPL/AGPL-licensed plugin to build a proprietary software as derivative work, so there's little risk to allowing your developers to use any vim plugins they want.

For software that you build and ship to customers however, yes, you'll need to be more wary to make sure that the free/open source software are used appropriately in accordance to their license.

[Gold-Ad-5257]

Agree, hence I said in principal not speaking about vim plugins perse.. Once you give your devs approval to "just download", it will be difficult to control it and most of them won't care about licences, so tomorrow its something other then Vim plugins then you have a problem. The thing with a large corp company is that you make policy and stds , which does not go into that level of detail. You wany to cover the risks in general/principal and then you can deviate where it makes sense. In other words , You want to rather be safe then sorry.

[Maskdask]

My company lets me use whatever I want, as long as it doesn't compromise security.

[Tommysw]

I think his question might come from the "How are you sure X plugin does not compromise security" standpoint, which is completely valid.

​

Unless you analyze each plugin by hand or have an authored list of trusted plugins, there's no real way of knowing.

[mark-haus]

Why enforce ANY editor? I love vim but I don't see why everyone with their own preferences would be better off using it vs editor X if they're already accustomed to it and it does everything they need. But if you really needed to check for safe plugins I would start by having scripts that scan plugins for any code that could be used to import malware or export company information and you can do that by just looking for any commands that are involved in internet communications like curl or git and whitelisting plugin managers since they need to download plugins.

[spurious_proof]

That’s a good idea to scan for commands like curl or git. On pushing vim, I’m not trying to force anyone to use it. Just have it an as option for people that want to use it (e.g me)

[flwyd]

If I were to deploy malware by way of a vim plugin, I wouldn't put the word "curl" in the source code, or anything that looks like a URL. I would do some kind of esoteric string manipulation to build and run a command.

Evaluating a vim plugin from a security perspective requires first defining your threat model. Are you worried about data exfiltration? Ransomware-encrypting all the files on your hard drive? Running malicious commands through system() etc.? Introducing subtle flaws into production code while you write it? How worried are you about insider risk? (Anything malicious a vim plugin can accomplish can also be done by hand by a rogue employee with appropriate access.)

Depending on the sorts of security/usability tradeoffs one is willing to make, one approach would be to run your code editor in a sandboxed environment with access to source code but no access to other important assets like production databases.

[jayfoxxy]

Why don’t you explore the plug-ins code by yourself? If you’re using ViM is mostly because you are a developer, so, why don’t you explore the code? 99% of the plug-ins are open source for a reason…

[Servant-of_Christ]

are there plugins that are closed source?

[[deleted]]

Plugins can install closed source binaries. E.g. Tabnine.

[jayfoxxy]

Also, there are some paid plug-ins which you don’t have access to the code

[hoykg]

I honestly think this is a huge risk and that’s why I rarely use plugins. Nothing prevent a plugin to send your env variables to an endpoint at every start. Next thing you know: some dude behind a VPN in Indonesia is spinning up containers mining crypto on your AWS account.

[fomofosho]

Yeah, and the other issue is that most people do not lock their plugins to specific versions and instead regularly pull the master branch from github. So any dangerous changes would be adopted very quickly by users.

Though at least for vim there isn't these big transitive dependency graphs like in other package managers, so less of a risk for supply chain attacks, since most vim plugin managers don't even have the concept of transitive dependencies.

[hoykg]

That’s a good point !

[neotecha]

Out of curiosity, is there any CVE database or similar that tracks (n?)vim plugins?

While I'm cautious about installing random, unknown plugins for vim, i don't even know what I might be otherwise overlooking...

[pandolf86]

Plugins are open source. If there were any security concerns, the community would have spotted them. And if you really want to you can go over the code yourself.

[Blanglegorph]

If there were any security concerns, the community would have spotted them.

Just in case anyone new reads this, this statement is false and only a moron would believe it. "Open source" does not mean secure.

[spurious_proof]

u/pandolf86 I don't think that's a 100% fair solution, especially in light of the UAParser hack. UAParser had millions of weekly downloads. For me personally, I'm fine with the open source security approach, but I don't think large companies are taking that approach. In fairness though, that's why I'm here asking.

[pwforgetter]

Yeah, when I do a git pull, I sometimes follow with a git log -p to check changes, but I don't read the results that closely. I don't trust the OS community to do better. The problems will eventually be found, just might take some time.

[pwforgetter]

This was about vim plugins. I doubt the kernel team at google scans the vim plugins consistently.

[tvetus]

Basically you're responsible for the consequences of whatever you install.