Some time ago, I read a blogpost from Doyensec that explained a simple but impactful vulnerability in a Visual Studio Code plugin – specifically, it leveraged Python virtual environments to execute arbitrary code when a malicious project was opened in the IDE. At the time, my job involved a lot of Python developing using JetBrain’s PyCharm, so I asked myself: is PyCharm vulnerable to something similar? This post summarizes the consequences of that question, which ultimately led to the discovery of CVE-2021-30005.

Disclaimer: this is a short post and the vulnerability is quite trivial. Don’t expect too much leetness :-P

The vulnerability

It’s a fairly simple issue: when opening a Python project, PyCharm (up to version 2020.3.4) automatically detects and activates any virtual environments found in the project. That’s a really convenient thing to do from a developer point of view: having to manually enable virtual environments for each project gets tedious very fast. But, from a security standpoint, that’s not so good.

We download projects from third parties and open them in our IDEs all the time, for various reasons. Like the good old “pipe this install script to sudo bash”, running code written by strangers is usually not a good idea, at least not before some inspection. The problem is that you will open the project in your IDE precisely to perform that inspection, and if your IDE automatically runs code from the project when you do that, well… You can get compromised before even realizing it.

Discovery

The test to confirm the vulnerability is easy: I just created a repository that already included a virtual environment, and I modified the bin/activate script (the one that gets executed when activating a virtual environment in Unix systems) to run an arbitrary command (open a calculator). After that, it was just a matter of cloning the repository, opening it in PyCharm and seeing the calculator pop up.

Whelp, it seems that indeed, the vulnerability exists!

PoC

You can find the PoC that I used here. Adjust the command in bin/activate (or the appropriate activation script for your OS) and make sure that you’re using a vulnerable version of PyCharm (<2020.3.4) if you want to reproduce the issue.

Mitigation

Although this is a simple vulnerability, its severity is quite high: execution of arbitrary commands. Technically, there’s not much more to discuss, but it opens and interesting conversation about trust in the open source landscape, and of course about the eternal discussion about convenience vs security. The folks at JetBrains did a great job reasoning about the trust topic in their blog, so instead of repeating it here I’ll just recommend you to read it there.

But TL;DR, the fix consisted in not executing anything by default when opening an untrusted project. To avoid losing the usability aspect of the feature, users have the ability to define trusted locations for projects, the virtual environments of which will get automatically activated. Cool!

Conclusion

In this blog post, I wanted to talk about this little but impactful discovery that initially seemed simple, but that in my opinion raised interesting questions about how to fix vulnerabilities like this without losing too much convenience, or about what trust means in software development, and it opens the door for a kind of attack that we’re just starting to witness – one in which the targets are no longer casual users, but developers themselves.