Exploit PoC for Remote code execution flaw in Visual Studio Code released

The remote code execution vulnerability that affected Visual Studio Code and was fixed by Microsoft in October was the subject of a proof-of-concept (PoC) attack that was made public online.

The security vulnerability, which has been given the identifier CVE-2022-41034, has the potential to give remote attackers complete control of susceptible computers. The simplicity of a code editor is combined with the functionality that developers want for the edit-build-debug cycle at the core of Visual Studio Code. It offers extensive support for code editing, navigation, and comprehension, in addition to lightweight debugging, a robust extension architecture, and lightweight interaction with tools that already exist.

The researchers demonstrated as a proof-of-concept (PoC) that it was feasible to attack CVE-2022-41034 to execute malicious code on the system from the perspective of a developer who is operating Visual Studio Code.

Because the researcher has disclosed a great deal of technical information, including a proof-of-concept attack for CVE-2022-41034, it is essential that the vulnerabilities be fixed as soon as humanly feasible.

An adversary may gain control of a computer used by a user of Visual Studio Code and any other machines to which they were linked by using the Visual Studio Code Remote Development function by accessing the computer via a link or website. At the very least, GitHub Codespaces and github.dev were impacted by this vulnerability, as well as the web-based Visual Studio Code for Web and, to a lesser degree, the desktop version of Visual Studio Code. Visual Studio Code has built-in support for the Jypiter Notebook format of rich text document. This format is also known as a Jypiter Notebook. Its primary use is in the field of data science, and it consists of several sections of code written in Python, Markdown, HTML, and other forms. On the system that serves as the viewer, the Python code is executed to produce the diagrams. Because it is risky to execute code that might be malicious, a Jypiter notebook will often start up in an untrusted mode by default, and the user will be prompted to indicate whether or not they trust the notebook. The majority of security constraints may be circumvented if the document is trusted, according to the researcher.