Improper SSH Host Key Validation (CWE-295) in mintupload – Man-in-the-Middle Vulnerability

[rgfegegeegege]

Description:

Vulnerability Overview
The mintupload tool (part of Linux Mint, version 4.2.2 as of January 2026) contains an insecure usage of Paramiko in the SFTP upload handler. Specifically, in mintupload_core.py (method _sftp of MintUploader), the code does:

ssh = paramiko.SSHClient()
ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())

AutoAddPolicy automatically accepts any unknown or changed SSH host key and adds it to the internal HostKeys object (and potentially to ~/.ssh/known_hosts if load_host_keys was called which it isn't here). This completely bypasses host key verification and opens the door to classic man-in-the-middle (MitM) attacks.

An attacker positioned between the user and the target server (e.g., rogue Wi-Fi, ARP poisoning on LAN, DNS spoofing) can:

• Intercept the first connection (or any subsequent one after known_hosts is cleared/ignored)
• Present their own forged host key
• mintupload accepts it silently without any user prompt, warning, or error
• All uploaded files are sent to the attacker instead of the real server

Since mintupload does not call load_system_host_keys() or load_host_keys(), it also never persists the accepted key to disk, making the behavior even worse: every run treats the server as "new" and blindly accepts whatever key is presented.

CVSS-like assessment (approximate):

• Attack Vector: Network (AV:N)
• Attack Complexity: Low (AC:L)
• Privileges Required: None (PR:N)
• User Interaction: None (UI:N)
• Scope: Unchanged (S:U)
• Confidentiality: High (C:H) – attacker reads files
• Integrity: High (I:H) – attacker can modify/drop files
• Availability: None (A:N)
  Base Score ~7.5 (High) in MitM scenarios, Low for typical desktop use (personal trusted servers).

Proof of Concept (full reproducible steps)
Tested on fresh Linux Mint Cinnamon 22.2 with mintupload 4.2.2 (January 11, 2026).

Setup:

# Generate two different host keys
ssh-keygen -t ed25519 -f ~/test_host_key_real -N "" -C "real"
ssh-keygen -t ed25519 -f ~/test_host_key_fake -N "" -C "fake"

# Start real server (port 2222 internal)
docker run -d \
  --name=ssh-real \
  -e PUID=1000 -e PGID=1000 \
  -e PASSWORD_ACCESS=true \
  -e USER_PASSWORD=testing123 \
  -e USER_NAME=unix \
  -p 2222:2222 \
  -v ~/test_host_key_real:/config/ssh_host_ed25519_key \
  linuxserver/openssh-server

Create service in mintupload-manager (GUI):

• Name: TestSFTP
• Type: SFTP
• Host: 127.0.0.1
• Port: 2222
• Username: unix
• Password: testing123
• Path: /config/
• Save Check connection (should succeed)

Exploit steps:

1. Upload any file (e.g. 5MB test file):

   dd if=/dev/zero of=~/big_poc.bin bs=1M count=5
   mintupload "TestSFTP" ~/big_poc.bin

   Success notification, file appears in container /config (verified with docker exec -it ssh-real ls -l /config)

2. Stop real, switch to fake key:

   docker stop ssh-real && docker rm ssh-real
   docker run -d \
     --name=ssh-fake \
     -e PUID=1000 -e PGID=1000 \
     -e PASSWORD_ACCESS=true \
     -e USER_PASSWORD=testing123 \
     -e USER_NAME=unix \
     -p 2222:2222 \
     -v ~/test_host_key_fake:/config/ssh_host_ed25519_key \
     linuxserver/openssh-server

3. Repeat upload (same service):

   mintupload "TestSFTP" ~/big_poc.bin

   success, no warning, no error. File now delivered to fake server.

Proof: The file was delivered to the server with a completely different host key (different fingerprint) without any user interaction or rejection. Classic MitM achieved.

Why this is dangerous
No user notification, no prompt, no rejection. Even after the first connection, if an attacker forces a key change (or known_hosts is cleared), the tool blindly trusts the new key.

Proposed fix (minimal & secure)
Replace the vulnerable lines in _sftp:

Before:

ssh = paramiko.SSHClient()
ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())

After:

ssh = paramiko.SSHClient()
ssh.load_system_host_keys()  # Use standard OpenSSH known_hosts if present
ssh.set_missing_host_key_policy(paramiko.RejectPolicy())  # Reject unknown/changed keys

Patch behavior:

• Unknown key raises SSHException / BadHostKeyException upload fails with clear error
• Known key (added manually via ssh once) works normally
• Changed key (MitM attempt) fails

Tested patch results (same environment):

• Unknown key: SSHException: Server '[127.0.0.1]:2222' not found in known_hosts
• After ssh -p 2222 unix@127.0.0.1 (added to known_hosts): upload succeeds
• Switched to fake key: BadHostKeyException: Host key ... does not match MitM blocked

Impact & Recommendation
Low real-world risk for most desktop users (personal servers, low exposure). Still worth fixing because:

• It's a textbook CWE-295 violation
• Tool is in default repos users may trust it
• Easy to exploit in untrusted networks

Recommended mitigation
Apply the patch above.
For users: add server keys manually first with ssh -p <port> user@host before using mintupload.

References:

• Paramiko docs: https://docs.paramiko.org/en/stable/api/client.html#paramiko.client.MissingHostKeyPolicy
• GitHub CodeQL rule: py-paramiko-missing-host-key-validation
• Bandit rule B507: ssh-no-host-key-verification

This is a real, exploitable issue. Patch is simple, standard, and preserves usability for trusted servers.

Discovered during local code review and PoC testing on Linux Mint 22.2.

:D