Back to skill

Security audit

alibabacloud-alinux-sysom-inspection

Security checks across malware telemetry and agentic risk

Overview

This skill mostly matches its SysOM inspection purpose, but it asks users to run an unverified remote installer as root and can trigger cloud service activation and agent installation from an inspection workflow.

Install only after reviewing the remote installer out of band or replacing it with a pinned, verified package. Run the skill with least-privilege Alibaba Cloud credentials, avoid broad region-wide mode unless intended, and expect that it may activate SysOM, install an agent on ECS, call cloud diagnosis APIs, and save local inspection reports.

Vulnerability Patterns
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (2)

T03 · Remote Payload Retrieval and Execution

Error
Location
SKILL.md:36
Finding
Unverified Remote Installer Is Executed with Root Privileges<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:36-40` **Vulnerability Type**: Remote payload retrieval and privileged execution **Risk Level**: Critical ### Vulnerable Code ```bash If it is missing, install it: ```bash curl -fsSL --connect-timeout 1000 https://sysom-prd-cn-hangzhou.oss-cn-hangzhou.aliyuncs.com/sysom_prd/skill_cli/install.sh | sudo bash ``` ``` ### Technical Analysis The documented installation procedure retrieves a shell script from a remote OSS URL and streams it directly into a root shell. The payload is not pinned to a version and is not verified using a cryptographic hash or trusted publisher signature before execution. HTTPS protects the download in transit, but it does not protect against compromise of the hosting account, replacement of the hosted object, erroneous publication, or loss of control over the distribution infrastructure. Because the object is mutable, the code ultimately executed can differ from the code reviewed during this audit. Piping the response directly to `sudo bash` also prevents meaningful inspection before execution and grants the downloaded payload unrestricted root-level access. This exceeds the privileges needed merely to download or invoke an ECS inspection client. ### Attack Path 1. An attacker compromises the OSS object, its publishing credentials, or the associated release process. 2. The attacker replaces `install.sh` with a malicious payload. 3. A user or agent follows the Skill setup instructions because `sysom-osops` is unavailable. 4. `curl` retrieves the modified script without checking a pinned digest or signature. 5. The script is passed directly to `sudo bash`. 6. The attacker-controlled code executes as root and can modify the host, collect credentials, establish persistence, or download additional payloads. ### Impact Assessment Successful exploitation provides arbitrary code execution with root privileges on the machine where the Skill is installed. The payload could ...[truncated 539 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Remove the `curl | sudo bash` installation pattern. 2. Distribute a versioned, immutable installer or package with a pinned release identifier. 3. Publish a SHA-256 digest through a separately protected channel and verify it before execution. 4. Sign release artifacts and validate the publisher signature using a pinned public key. 5. Download the installer to a local file, validate it, and permit inspection before running it. 6. Avoid running the entire installer as root. Separate the specific operations requiring elevation and execute only those operations with `sudo`. 7. Prefer installation through a trusted package repository with signed metadata and version pinning. 8. Ensure updates require the same integrity checks rather than retrieving a mutable latest-version payload. 9. Document the exact files, permissions, services, and network endpoints used by the installer so its privilege requirements can be independently reviewed. A safer workflow would resemble: ```bash curl -fSLo sysom-install.sh "https://trusted.example/versioned/sysom-install-0.2.0.sh" echo "<PINNED_SHA256> sysom-install.sh" | sha256sum --check - # Verify a publisher signature as well. less sysom-install.sh bash sysom-install.sh ``` Any individual operation that genuinely requires root access should request elevation separately rather than granting root privileges to the entire downloaded script. ]]>

T08 · Insecure Dependencies

Warning
Location
scripts/sysom_cli/__main__.py:12
Finding
CLI Automatically Installs Mutable, Unpinned Dependencies at Runtime<![CDATA[ ## Vulnerability Details **File Location**: `scripts/sysom_cli/__main__.py:12-34` **Supporting Locations**: `scripts/requirements.txt:1-3`, `scripts/init.sh:7-8`, `scripts/pyproject.toml:5-14` **Vulnerability Type**: Insecure dependency installation and supply-chain exposure **Risk Level**: Medium ### Vulnerable Code ```python # module import name -> pip package name _DEPS = { "requests": "requests", "alibabacloud_tea_openapi": "alibabacloud-tea-openapi", "alibabacloud_tea_util": "alibabacloud-tea-util", } def _ensure_deps() -> None: missing = { pip_name for mod_name, pip_name in _DEPS.items() if importlib.util.find_spec(mod_name) is None } if not missing: return print( f"[Setup] Installing missing dependencies: {', '.join(sorted(missing))}", file=sys.stderr) try: subprocess.check_call( [sys.executable, "-m", "pip", "install", "--quiet", *sorted(missing)], ) ``` The supporting dependency specifications use open version ranges rather than immutable versions and hashes: ```text requests>=2.31.0 alibabacloud-tea-openapi>=0.4.4,<1.0.0 alibabacloud-tea-util>=0.3.14,<1.0.0 ``` ### Technical Analysis The CLI invokes `pip install` automatically when a dependency is absent. Package names are fixed rather than directly controlled by command-line input, so this is not a shell-command injection issue. The risk arises because dependency retrieval and code installation occur implicitly during ordinary CLI startup. No exact versions, package hashes, or trusted package index are supplied to the runtime `pip` command. Resolution therefore depends on the user's pip configuration and the newest matching packages available at execution time. This makes the installed code mutable and non-reproducible. The broad version constraints in `requirements.txt` and `pyproject.toml` have the same integrity limitation. If the configured index, a matching ...[truncated 1681 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Remove automatic dependency installation from CLI startup. 2. Fail safely with a clear setup instruction when dependencies are missing. 3. Generate and maintain a lock file containing exact dependency and transitive-dependency versions. 4. Require hashes for all downloaded distributions, such as with pip's `--require-hashes` mode. 5. Install dependencies in a dedicated virtual environment during an explicit setup phase. 6. Configure an approved HTTPS package index rather than inheriting arbitrary user or system pip index settings. 7. Review and update locked dependencies through a controlled release process. 8. Prefer prebuilt, signed application artifacts where practical. 9. Ensure CI verifies that the dependency lock is reproducible and that package hashes match expected values. 10. Avoid upgrading pip automatically in production setup unless the pip artifact is also pinned and integrity-verified. The CLI should report missing dependencies without modifying the environment, for example: ```python if missing: raise SystemExit( "Missing dependencies. Install the reviewed, hash-locked requirements " "in an isolated virtual environment before running this command." ) ``` Installation should then be an explicit administrative action using a reviewed lock file: ```bash python3 -m venv .venv .venv/bin/python -m pip install \ --require-hashes \ --only-binary=:all: \ -r requirements.lock ``` ]]>
Vulnerability Patterns
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • Behavioral ASTexec() Call, eval() Call, Dynamic Import
  • MCP Least PrivilegeUnderdeclared Capability, Wildcard Permission, Missing Permission Declaration
Findings (12)

subprocess module call

Medium
Category
Dangerous Code Execution
Content
print(
        f"[Setup] Installing missing dependencies: {', '.join(sorted(missing))}", file=sys.stderr)
    try:
        subprocess.check_call(
            [sys.executable, "-m", "pip", "install",
                "--quiet", *sorted(missing)],
        )
Confidence
94% confidence
Finding
The CLI automatically invokes pip at runtime to install missing packages, which executes an external package manager and mutates the local environment during normal command execution. Even though shell injection is not present because arguments are passed as a list and package names are hardcoded, this still creates a supply-chain and unexpected code-execution risk if package indexes, mirrors, or the Python environment are compromised.

Lp3

Medium
Category
MCP Least Privilege
Confidence
87% confidence
Finding
The skill documentation indicates capabilities to access environment variables, read/write local files, invoke shell commands, and use the network, yet no explicit permissions model is declared. That creates an authorization transparency gap: users may invoke a skill that can install software, fetch credentials, and write reports without a clear declaration of what access is required or exercised.

Tp4

High
Category
MCP Tool Poisoning
Confidence
95% confidence
Finding
The documented behavior substantially exceeds the stated purpose of simple inspection: it can activate services, install agents, enumerate instances, obtain credentials from multiple sources, assume RAM roles, and write local report files. This mismatch undermines informed consent and increases the risk of unexpected privileged actions or credential exposure in environments where the user expected read-only diagnostics.

Context-Inappropriate Capability

Medium
Confidence
97% confidence
Finding
A health-inspection skill should not need to install Python packages dynamically during execution, so this capability is broader than its stated purpose and increases attack surface. Runtime package installation can pull and execute untrusted code from package repositories, alter the host environment, and create non-deterministic behavior, which is especially risky for an operational diagnostic tool likely to run on production systems.

Description-Behavior Mismatch

Medium
Confidence
95% confidence
Finding
The command marketed as inspection/diagnosis can also activate SysOM and install an agent on the target instance, which are state-changing administrative actions. Although there is an interactive prompt in TTY mode, the prompt understates the impact and in some contexts a user may invoke what appears to be a read-only health check but instead authorize software deployment and service activation.

Vague Triggers

Medium
Confidence
82% confidence
Finding
Broad trigger keywords such as generic inspection and memory-usage terms can cause the skill to activate on ordinary troubleshooting prompts, increasing the chance of unintended execution. In this skill, unintended execution is more serious because it may lead to broad regional inspections, automatic diagnosis flows, network activity, and potentially installation/activation side effects.

Missing User Warnings

Medium
Confidence
90% confidence
Finding
The documentation promotes automated inspection, diagnosis, and region-wide/batch workflows without a clear warning about operational scope, data access, and possible side effects such as service activation, agent installation, and broad instance enumeration. Users may therefore authorize actions affecting many systems or exposing telemetry/log data without understanding the breadth of access involved.

Missing User Warnings

Medium
Confidence
94% confidence
Finding
The code installs an agent after only a generic prompt about activation and installation, without an explicit warning that software will be deployed onto the target ECS instance. This can cause unexpected changes to production hosts, compliance issues, or user confusion because the consent text does not clearly match the sensitivity of the action.

Missing User Warnings

Low
Confidence
82% confidence
Finding
The command persists inspection and diagnosis results to disk automatically, potentially including instance identifiers, anomaly details, process names, and command lines. Silent local storage can expose operationally sensitive data to other local users, backup systems, or unintended retention paths when the user expected transient console output only.

Unpinned Dependencies

Low
Category
Supply Chain
Content
requests>=2.31.0
alibabacloud-tea-openapi>=0.4.4,<1.0.0
alibabacloud-tea-util>=0.3.14,<1.0.0
Confidence
95% confidence
Finding
The dependency specification uses a lower-bound only for requests, which permits installation of many different future versions and undermines reproducible builds. This is a supply-chain risk because environments may resolve to unexpected versions, including versions later found vulnerable or incompatible, though the file itself does not prove immediate exploitation.

Known Vulnerable Dependency: requests — 10 advisory(ies): CVE-2014-1830 (Exposure of Sensitive Information to an Unauthorized Actor in Requests); CVE-2024-47081 (Requests vulnerable to .netrc credentials leak via malicious URLs); CVE-2024-35195 (Requests `Session` object does not verify requests after making first request wi) +7 more

High
Category
Supply Chain
Confidence
90% confidence
Finding
The project declares a dependency on requests with a broad lower-bound constraint (>=2.31.0), and the analyzer reports multiple known advisories affecting some requests versions. Because the version range is not capped to exclude vulnerable releases, dependency resolution could select an affected version in some environments, creating risk for credential leakage, TLS/verification issues, or other client-side request handling flaws.

Known Vulnerable Dependency: requests==2.31.0 — 6 advisory(ies): CVE-2024-47081 (Requests vulnerable to .netrc credentials leak via malicious URLs); CVE-2024-35195 (Requests `Session` object does not verify requests after making first request wi); CVE-2026-25645 (Requests has Insecure Temp File Reuse in its extract_zipped_paths() utility func) +3 more

Medium
Category
Supply Chain
Confidence
89% confidence
Finding
The requirement allows installation of requests 2.31.0 because the specifier is requests>=2.31.0, and that version is associated with multiple advisories. If dependency resolution selects 2.31.0 in some environments, the skill could inherit request-handling weaknesses such as credential leakage or verification issues, which is relevant for a cloud inspection skill likely making outbound API calls.

VirusTotal

VirusTotal findings are pending for this skill version.

View on VirusTotal

Static analysis

Detected: suspicious.exposed_resource_identifier

Plaintext HTTP endpoint targets a CGNAT/Tailscale-range address.

Critical
Code
suspicious.exposed_resource_identifier
Location
scripts/sysom_cli/lib/auth.py:57