Overview

On many platforms, a third party can create a Git repository under a name that includes a shell command substitution [^1] string in the syntax $(<command>). These directory names are allowed in macOS and a majority of Linux distributions [^2]. If a user starts jupyter-lab in a parent directory of this inappropriately-named Git repository, opens it, and clicks "Git > Open Git Repository in Terminal" from the menu bar, then the injected command <command> is run in the user's shell without the user's permission.

This issue is occurring because when that menu entry is clicked, jupyterlab-git opens the terminal and runs cd <git-repo-path> through the shell to set the current directory [^3]. Doing so runs any command substitution strings present in the directory name, which leads to the command injection issue described here. A previous patch provided an incomplete fix [^4].

[^1]: https://www.gnu.org/software/bash/manual/htmlnode/Command-Substitution.html [^2]: https://www.gnu.org/software/libc/manual/htmlnode/File-Name-Portability.html [^3]: https://github.com/jupyterlab/jupyterlab-git/blob/7eb3b06f0092223bd5494688ec264527bbeb2195/src/commandsAndMenu.tsx#L175-L184 [^4]: https://github.com/jupyterlab/jupyterlab-git/pull/1196

Scope of Impact

This issue allows for arbitrary code execution via command injection. A wide range of actions are permitted by this issue, including but not limited to: modifying files, exfiltrating data, halting services, or compromising the server's security rules.

We have scanned the source code of jupyterlab-git for other command injection risks, and have not found any at the time of writing.

This issue was reproduced on the latest release of jupyterlab-git, v0.51.0. The steps taken to reproduce this issue are described in the "Proof-of-concept" section below.

Proof-of-concept

1. Create a new directory via mkdir test/ && cd test/.

2. Create a new Git repository under test/ with a command substitution string in the directory name by running these commands:

mkdir '$(touch pwned.txt)' cd '$(touch pwned.txt)/' git init cd ..

3. Start JupyterLab from test/ by running jupyter lab. 4. With JupyterLab open in the browser, double click on $(touch pwned.txt) in the file browser. 5. From the top menu bar, click "Git > Open Git Repository in Terminal". 6. Verify that pwned.txt is created under test/. This demonstrates the command injection issue described here.

Proof-of-concept mitigation

The issue can be mitigated by the patch shown below.

<details><summary>Patch (click to expand)</summary>

diff diff --git a/src/commandsAndMenu.tsx b/src/commandsAndMenu.tsx index 3779a6c..71ddcea 100644 --- a/src/commandsAndMenu.tsx +++ b/src/commandsAndMenu.tsx @@ -164,31 +164,13 @@ export function addCommands( label: trans.('Open Git Repository in Terminal'), caption: trans.('Open a New Terminal to the Git Repository'), execute: async args => { - const main = (await commands.execute( - 'terminal:create-new', - args - )) as MainAreaWidget<ITerminal.ITerminal>; + const cwd = gitModel.pathRepository; + const main = (await commands.execute('terminal:create-new', { + ...args, + cwd + })) as MainAreaWidget<ITerminal.ITerminal>; - try { - if (gitModel.pathRepository !== null) { - const terminal = main.content; - terminal.session.send({ - type: 'stdin', - content: [ - cd "${gitModel.pathRepository - .split('"') - .join('\\"') - .split('') - .join('\\')}"\n - ] - }); - } - - return main; - } catch (e) { - console.error(e); - main.dispose(); - } + return main; </details>

This patch removes the cd <git-repo-path> shell command that causes the issue. To preserve the existing behavior, the cwd argument is set to <git-repo-path> when a terminal session is created via the terminal:create-new JupyterLab command. This preserves the existing application behavior while mitigating the command injection issue.

We have verified that this patch works when applied to a local installation of jupyterlab-git. We have also verified that the cwd argument is available in all versions of JupyterLab 4, so this patch should be fully backwards-compatible.

Workarounds

We recommend that users upgrade to the patched versions listed on this GHSA. However, if a user is unable to upgrade, there are 3 different ways to mitigate this vulnerability without upgrading to a patch.

1. Disable terminals on jupyter-server level: c.ServerApp.terminalsenabled = False

2. Disable the terminals server extension: jupyter server extension disable jupyterserverterminals

3. Disable the lab extension: jupyter labextension disable @jupyterlab/terminal-extension

In Jupyter Notebook versions 7.0.0 through 7.5.5, JupyterLab versions 4.5.6 and earlier, and the corresponding @jupyter-notebook/help-extension and @jupyterlab/help-extension packages before 7.5.6 and 4.5.7, a stored cross-site scripting issue in the help command linker can be chained with attacker-controlled notebook content to steal authentication tokens with a single click.

An attacker can craft a malicious notebook file containing elements that appear indistinguishable from legitimate controls and trigger execution when a user interacts with them. Successful exploitation allows theft of the user's authentication token and complete takeover of the Jupyter session through the REST API, including reading files, creating or modifying files, accessing kernels to execute arbitrary code, and creating terminals for shell access. This issue has been fixed in Notebook 7.5.6, JupyterLab 4.5.7, @jupyter-notebook/help-extension 7.5.6, and @jupyterlab/help-extension 4.5.7. As a workaround, disable the affected help extensions or set allowCommandLinker to false in the sanitizer configuration.