Installer manage.py disables TLS certificate verification, then downloads and bash-executes get-docker.sh (MITM → RCE)

Summary

The official installer/manager scripts/manage.py disables TLS certificate verification for all its outbound HTTPS downloads, and one of those downloads (get-docker.sh) is then executed with bash. Because verification is off, a network attacker positioned between the host and the download server can substitute arbitrary content for that script, which then runs on the installing machine (typically as root). I wanted to raise it privately, but the repo has no SECURITY.md and private vulnerability reporting is turned off, so I'm reporting it here — happy to move it to a private channel if you have one.

What I observed (facts, at commit 6d871e6)

init_global_config() sets a single shared SSL context with verification disabled:

1# scripts/manage.py
2499:    REQUEST_CTX = ssl.create_default_context()
3500:    REQUEST_CTX.check_hostname = False
4501:    REQUEST_CTX.verify_mode = ssl.CERT_NONE

That context is the only one used for downloads:

1586: def get_url(url):
2588:        response = urlopen(url, timeout=10, context=REQUEST_CTX)
31195: def save_file_from_url(url, path):   # uses get_url under the hood

And install_docker() downloads then executes a shell script fetched this way:

1731:    if not save_file_from_url('https://'+DOMAIN+'/release/latest/get-docker.sh','get-docker.sh'):
2744:    r = exec_command_with_loading('bash get-docker.sh', env=env)

DOMAIN is waf-ce.chaitin.cn / waf.chaitin.com. The same unverified context also fetches compose.yaml and version.json.

Why I think it matters (my inference — not a proven exploit)

With check_hostname=False + CERT_NONE, HTTPS still encrypts but no longer authenticates the server, and there's no checksum/signature check on the downloaded script to compensate. An active MITM (hostile Wi-Fi, DNS spoofing, a compromised upstream proxy) could serve a malicious get-docker.sh, which manage.py then runs via bash — a remote-code-execution path on the installing host. It felt worth flagging carefully because this ships in a security product.

Suggested fix (I can send a small PR)

Keep the secure defaults — ssl.create_default_context() already validates the CA chain and hostname, so the two override lines can simply be removed:

1REQUEST_CTX = ssl.create_default_context()   # verifies by default; drop the CERT_NONE override

If a specific host genuinely needs an exception, scoping it to that host (rather than disabling verification globally) would keep the rest of the downloads authenticated. Optionally, verifying a published checksum of get-docker.sh before executing it would add defense-in-depth.

I checked open and closed issues and didn't find an existing report for this. I'm glad to open a PR with the one-line change if that's welcome.

Disclosure: I used an AI tool to help find this and draft the report; I read scripts/manage.py at the commit above and verified every line and path myself, and I take responsibility for it.

Thanks for the detailed report and PR #1305. We’ve confirmed the issue and will review the proposed fix.

thx https://github.com/chaitin/SafeLine/commit/43a361d4731b672844e0e193784b60913b017479