Description
During a security review of the mytonctrl deployment infrastructure, I analyzed the behavior of the install.sh script. While the script is intended to be executed by an administrator with root privileges, implementing stricter security practices (hardening) will prevent accidental local abuse, symlink race conditions, and supply-chain injection risks in shared or automated deployment environments.
Below is a detailed analysis of three focus areas along with concrete remediation examples.
1. Insecure sourcing of environmental files (--env-file)
if [ -n "$env_file" ]; then
...
source "$env_file"
fi
------------------------------------------------------------------------------------------------------------------
Risk Analysis: The source (or .) command executes the target file directly within the current shell context under root privileges. If the installation environment is shared or if an administrator points to a world-writable configuration file, any arbitrary shell commands embedded in that file will instantly execute with root permissions.
Remediation Suggestion: Instead of sourcing the entire file dynamically, parse only the specific expected key-value pairs (variables), or strictly enforce permission checks (e.g., ensuring the file is owned by root and has 600 permissions) before execution.
2. Lack of validation for source control parameters (--author and --repo)
Target Code:
wget [https://raw.githubusercontent.com/$](https://raw.githubusercontent.com/$){author}/${repo}/${branch}/scripts/install.py
python3 install.py "$@"
------------------------------------------------------------------------------------------------------------------
Risk Analysis: The script implicitly trusts user-supplied arguments for GitHub repository structure and executes the resulting install.py without verifying the repository's signature or domain context. A typo or social engineering vector could lead an operator to pull deployment scripts from an untrusted fork.
Remediation Suggestion: Implement a strict whitelist validation for acceptable --author and --repo arguments, or restrict the installer to the official ton-blockchain scope by default unless an explicit --dev-override flag is passed.
------------------------------------------------------------------------------------------------------------------
3. Predictable file paths in shared temporary directories (/tmp)
Target Code:
wget [https://raw.githubusercontent.com/.../install_clang.sh](https://raw.githubusercontent.com/.../install_clang.sh) -O /tmp/install_clang.sh
bash /tmp/install_clang.sh
------------------------------------------------------------------------------------------------------------------
Risk Analysis: Writing to fixed filenames like /tmp/install_clang.sh in a world-writable directory (/tmp) opens up a window for symlink race conditions. A low-privileged malicious actor on a shared host could pre-create a symlink at that path pointing to a critical system configuration file. When install.sh runs via sudo, wget will overwrite the targeted system file.
Remediation Suggestion: Utilize the standard Linux mktemp utility to generate unpredictable, secure temporary filenames:
------------------------------------------------------------------------------------------------------------------
TMP_SCRIPT=$(mktemp /tmp/install_clang.XXXXXX.sh)
wget "URL" -O "$TMP_SCRIPT"
bash "$TMP_SCRIPT"
rm -f "$TMP_SCRIPT"
------------------------------------------------------------------------------------------------------------------
Conclusion
Applying these structural enhancements will make the mytonctrl installation lifecycle significantly more resilient against environment-based risks. I would be glad to receive feedback from the TON Core security team regarding these recommendations!
Submitted by: Danil (Independent Security/QA Researcher)
Contact: Telegram @psychoprofile
Description
During a security review of the
mytonctrldeployment infrastructure, I analyzed the behavior of theinstall.shscript. While the script is intended to be executed by an administrator with root privileges, implementing stricter security practices (hardening) will prevent accidental local abuse, symlink race conditions, and supply-chain injection risks in shared or automated deployment environments.Below is a detailed analysis of three focus areas along with concrete remediation examples.
1. Insecure sourcing of environmental files (
--env-file)