Security researchers have found new instances of code repositories with malicious code in the tasks.json configuration file, set to execute automatically when the folder is opened in Visual Studio Code (VS Code).
In this case, VS Code is working as designed. The tasks.json file enables developers to integrate command-line tools with the editor, so that they can be executed using the Run Task or Run Build Task commands. There is also an option to run tasks automatically when the containing folder is opened. The tasks.json file, when specific to a repository, is located within the hidden .vscode folder.
VS Code has two protections against undesirable tasks running automatically. One is the setting Allow Automatic Tasks, which defaults to on. Second, and perhaps more, is that folders are untrusted by default, and tasks do not run in untrusted folders. Opening a folder that contains an auto-execute task triggers a prompt warning that “creating a terminal process requires executing code.”
That said, the warning dialog highlights the “trust folder and continue” option, conveying a visual message that is at odds with the text content. In addition, VS Code has an option to trust all folders within a parent folder, and if this has been checked in the past, the new sub-folder will be trusted by default.
Security companies love to hype the risks they have found, and given that this is not a vulnerability in VS Code the issue is perhaps overstated; the real problem is the existence of malicious repositories which, according to the team at jamf, are often opened “under the pretext of a recruitment process or technical assignment.” Even without a malicious auto-running task an infected repository is dangerous.
It is arguable though that the design of VS Code could be improved in this respect. “It is scary that a text editor can run hidden code just by opening a folder … users will always click the button to trust a file if they think it helps them work faster. We cannot blame them when the software design makes it so easy to make a mistake,” said one comment on the latest issue.
This particular example, discovered this week, sets up a backdoor which can be used by the attackers for “remote code execution, system fingerprinting, and persistent C2 [command and control] communication.” The code uses a feature of tasks.json that allows different commands to run depending on the operating system, with variations for macOS, Windows and Linux. Malicious JavaScript is retrieved from a remote location using the curl utility.
The bad repository was hosted on GitHub and has now been removed, while the JavaScript payload was hosted by Vercel. Hosting the bad code externally, rather than in the repository itself, makes it harder for GitHub’s security tools to scan.
How then can developers protect themselves? The researchers state the obvious: that before marking a repository as trusted “it’s important to review its contents,” but this is impractical when there is a significant amount of code. More to the point is the advice to be “cautious when interacting with third-party repositories.”
Other ideas include developing in isolated, ephemeral environments where running untrusted code is less consequential. “Developing inside containers should be default workflow,” said another coder.