Privilege escalation vulnerability in Anaconda3 and Miniconda3

During a customer engagement, I discovered a privilege escalation vulnerability (CVE-2022-26526) in Anaconda3[1] and Miniconda3[2] on Windows. This vulnerability is at the time of writing not patched by the vendor, and in accordance with the deadlines of Improsec’s Responsible Disclosure Policy, we release the vulnerability information.

The vulnerability is found in a non-default installation scenario of Anaconda3 and Miniconda3, in which:

  • A world-writable directory is created in %ProgramData%, e.g. “C:\ProgramData\Anaconda3”

  • Multiple paths of the world-writable directory are prepended to the system’s %PATH% environment variable

This allows may allow a local low privileged user to escalate privileges. Additionally, the insecure %ProgramData% permissions allow a local low privileged user to hijack the Anaconda3 and Miniconda3 execution flow in various ways and potentially compromise other Anaconda3 users on a shared system.

These vulnerabilities are defined as:

  • MITRE Common Weakness Enumeration: CWE-426: Untrusted Search Path[3]

  • MITRE ATT&CK technique: T1574.007, Hijack Execution Flow: Path Interception by PATH Environment Variable[4]

For some reason, MITRE does not recognize this as T1574.007, although in my opinion, it is the correct technique to describe the attack. MITRE’s response was:

The latest release of the applications at the time of writing are still vulnerable: Anaconda3 version 2021.11.0.0, and Miniconda3 version 11.0.0.0

Since the vulnerability is not fixed, I advise anyone with the described vulnerable installation scenario to do one of the following on systems where a privilege escalation is not accepted:

  • Remove “BUILTIN\Users” write permission the application’s %ProgramData% directory by disabling inheritance and removing the permission.

  • Remove the application’s paths from the system’s PATH variable.

CVE registered

CVE-2022-26526, a CVSS of 8.2 (AV:L/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H/E:H/RL:U/RC:C)

Affected versions

  • Anaconda3 version 2021.11.0.0 and likely prior versions

  • Miniconda3 version 11.0.0.0 and prior versions, at least since 10.3.0.0

Responsible disclosure timeline

  • December 16, 2021 – Vulnerability discovered.

  • December 16, 2021 – Reached out to Anaconda via their knowledge base, attempting to get contact address.

  • December 16, 2021 – Response from Anaconda with responsible disclosure contact details.

  • December 17, 2021 – Shared vulnerability with Anaconda.

  • December 23, 2021 – Vulnerability confirmed by Anaconda.

  • January 10, 2021 – Asked for info on fixed versions, was told I will get info when they “have more information”.

  • February 23, 2022 – Asked for status, was told “work is still in progress”.

  • March 11, 2022 – Asked for status, was told “issue is still being actively researched and worked on internally”.

  • March 17, 2022 – Blog post is public in accordance with Improsec’s Responsible Disclosure Policy.

 
Installation scenario

The vulnerability is present in the following installation scenario:

  1. Install for: All Users (required admin privileged)” has been chosen as installation type – this installs Miniconda3 in ”%ProgramData%\Anaconda3

2. ”Add Anaconda3 to the system PATH environment variable” has been chosen in advanced installation options – this prepends the following to the system PATH variable ”C:\ProgramData\Anaconda3;C:\ProgramData\Anaconda3\Library\mingw-w64\bin;C:\ProgramData\Anaconda3\Library\usr\bin;C:\ProgramData\Anaconda3\Library\bin;C:\ProgramData\Anaconda3\Scripts;

3. The default Windows on “%ProgramData%” for “BUILTIN\Users” that allows write with the ContainerInherit” flag has not been changed on the system:

These are screenshots of the same Miniconda3 installation scenario:

Demonstration of privilege escalation

If a high privileged account attempts to execute anything from the system’s PATH variable, the executable will first be attempted to be found in the Anaconda3 and Miniconda3 directories.

For example by executing regedit in Command Prompt:

Viewing the behind the scenes with Process Monitor we see cmd.exe attempting to locate regedit (.COM, .EXE and so on will be searched for…), it does this by searching each of the system’s PATH variable, when it is found it is executed:

Again, looking at cmd.exe behavior we see execution of the malicious executable:

Not only can the privilege escalation be triggered by administrative users, but by any process/service calling CreateFile without a direct path.

 

Cases in the wild

I found at least one instance of someone deploying Anaconda with the vulnerable configuration by searching for the installation scenario arguments: