Back to skill

Security audit

Kaggle Openmm Md Runbook

Security checks for vulnerabilities and agentic risk

Overview

This is a coherent Kaggle molecular-dynamics runbook with disclosed account-operation steps, but users should only run the Kaggle and supervisor commands intentionally because they can spend quota and mutate Kaggle resources.

Install only if you intend to manage Kaggle OpenMM runs. Review the Kaggle commands before use, keep credentials in the standard Kaggle config, replace example owner/slugs with your own resources, run only one supervisor loop, and prefer locked dependencies for reproducible or sensitive work. Do not rely on the README's printed expected SKILL.md hash until the publisher updates it.

Vulnerability Patterns
  • 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
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (1)

T08 · Insecure Dependencies

Warning
Location
RUNBOOK.md:195
Finding
Unverified and Unlocked Third-Party Dependencies in the Runtime Bootstrap<![CDATA[ ## Vulnerability Details **File Location**: `RUNBOOK.md:195-219`; additional occurrence at `SKILL.md:206` **Vulnerability Type**: Supply-chain exposure through floating dependencies and installation without artifact hash verification **Risk Level**: Medium ### Vulnerable Code Snippets `RUNBOOK.md:195-219`: ```bash micromamba create -y -n md -c conda-forge \ python=3.12 openmm=8.3.1 openmmforcefields openff-toolkit \ openff-forcefields ambertools rdkit pdbfixer mdtraj pyyaml scipy # reproducible variant (review once, reuse): after the first successful solve — # micromamba env export -n md > conda-linux-64.lock # micromamba create -y -n md --file conda-linux-64.lock # openmm=8.3.1 is the safety-critical hard pin (R02); the helper packages float by # design on an ephemeral session — pin them via the lock if you need bit-reproducibility. # sanity check: micromamba run -n md python -c "import openmm; print(openmm.__version__)" # then: micromamba run -n md python <abs path to run.py> --engine ``` The accompanying disclosure confirms that most packages are intentionally unlocked: ```text The conda env itself: only openmm=8.3.1 is safety-critical and hard-pinned; the remaining packages (openmmforcefields, openff-toolkit, ambertools, rdkit, mdtraj, …) float at conda-forge HEAD of the day. They were verified against OpenMM 8.3.1 across v34–v56, but bit-identical reproducibility requires exporting micromamba env export from a known-good session and re-creating from that spec file. ``` `SKILL.md:206`: ```bash pip install -q kaggle==2.2.4 && chmod 600 ~/.kaggle/kaggle.json # pinned CLI; user-provided key; standard hygiene ``` ### Technical Analysis The runtime environment is reconstructed during every Kaggle session. Although `openmm=8.3.1` and `kaggle==2.2.4` are version-pinned, most Conda dependencies have neither exact versions nor exact build identifiers. The resolver can therefore select different executable artifacts whenever the bootstra ...[truncated 3015 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. **Publish a reviewed explicit Conda lock file** - Resolve the environment from a trusted, known-good system. - Lock every package to an exact version, build identifier, platform, and repository URL. - Commit the reviewed lock file to the Skill. - Replace the floating environment creation command with: ```bash micromamba create -y -n md --file conda-linux-64.lock ``` 2. **Verify the lock file before use** - Publish the expected SHA-256 digest of the lock file in a separately reviewed manifest. - Verify the digest before creating the environment. - Treat any unexpected change to the lock file or manifest as a security-sensitive review event. 3. **Use hash-verified Python package installation** - Produce a requirements file containing the exact Kaggle CLI version and artifact hash. - Install with hash enforcement, for example: ```bash python3 -m pip install --require-hashes -r requirements-kaggle.txt ``` 4. **Reduce runtime privilege** - Prefer a user-writable installation directory such as `$HOME/.local/bin` instead of `/usr/local/bin` where practical. - Run dependency installation and the simulation as a non-root user when the Kaggle environment permits it. - Expose credentials only to the process that requires them and only for the duration of the API operation. 5. **Separate dependency installation from credential availability** - Do not make Kaggle credentials available while installing or initially importing newly resolved packages. - Complete integrity checks before exposing private datasets or authentication material. 6. **Add continuous supply-chain validation** - Generate a software bill of materials for each approved environment. - Scan locked artifacts for known vulnerabilities and unexpected provenance changes. - Require human review before updating any dependency or lock file. - Preserve known-good package artifacts or use a controlled m ...[truncated 69 chars]
Vulnerability Patterns
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • Rogue AgentSelf-Modification, Session Persistence
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
Findings (5)

Context-Inappropriate Capability

Medium
Confidence
94% confidence
Finding
The runbook explicitly instructs an agent to rely on a persisted Kaggle API credential and to perform authenticated remote actions such as status checks, pulls, pushes, dataset versioning, and relaunches. Even if intended for legitimate MD job orchestration, this grants the skill authority to act on an external account, which is risky when the skill purpose does not tightly constrain or technically sandbox what account actions may be taken.

Intent-Code Divergence

Medium
Confidence
91% confidence
Finding
The script explicitly claims it 'writes nothing outside temp dirs' and is 'safe to run anywhere', but it invokes `learn.py --selftest` without any containment or verification that the learning self-test is read-only. If `learn.py` updates repository files, caches, or lesson artifacts, operators may run this script in trusted environments under false assumptions, causing unintended state changes and masking supply-chain tampering.

Sudo/Root Execution

Medium
Category
Privilege Escalation
Content
curl -fsSL "https://micro.mamba.pm/api/micromamba/linux-64/${MM_VER}" -o "$MM_TARBALL"
printf '%s  %s\n' "$MM_SHA" "$MM_TARBALL" | sha256sum -c -          # aborts on mismatch
tar -xjf "$MM_TARBALL" -C "$MM_DIR" bin/micromamba                   # single reviewed member
# (Kaggle images run as root, so /usr/local/bin is writable — verified v34–v56 and in the
#  2026-09-08 kernel; on a non-root host install to "$HOME/.local/bin" instead and put it on PATH)
install -m 0755 "$MM_DIR/bin/micromamba" /usr/local/bin/micromamba
micromamba --version
Confidence
79% confidence
Finding
The runbook directs installation of a fetched binary into /usr/local/bin in a root-capable environment. Although the tarball is pinned and SHA-256 verified, any compromise of the source, checksum provenance, or surrounding bootstrap logic would yield privileged code execution and persistence within the session environment.

Session Persistence

Medium
Category
Rogue Agent
Content
# 4. restart the background supervisor (dies with the sandbox; start exactly one)
cd /path/to/md_run && INTERVAL=900 KAGGLE_ACCOUNT=<owner> \
  nohup python3 md_supervisor.py loop >/dev/null 2>&1 &   # user-started, self-stopping; dies with the sandbox

# 5. before ANY push: static preflight (this skill) + local CPU dry run (kernel's MBZ_DRY)
python3 SKILL_DIR/scripts/md_preflight.py --kernel kernels/ --input input/
Confidence
91% confidence
Finding
The documented use of `nohup python3 md_supervisor.py loop ... &` creates a background persistence mechanism that can continue acting without an interactive session. Although the skill tries to bound this behavior with human approval and stop conditions, persistence plus remote-mutating commands (`kaggle kernels push`, dataset versioning/relaunch) increases the risk of unattended repeated actions, duplicate loops, or misuse if an agent ignores the stated safeguards.

External Script Fetching

High
Category
Supply Chain
Content
MM_VER=1.5.10
MM_SHA=cc37fae8210520b4d3bd46156d46bf7af10e775cd2efc7c05f1fc7251c20ac96   # publisher tarball, verified 2026-09-09
MM_TARBALL="$(mktemp)"; MM_DIR="$(mktemp -d)"
curl -fsSL "https://micro.mamba.pm/api/micromamba/linux-64/${MM_VER}" -o "$MM_TARBALL"
printf '%s  %s\n' "$MM_SHA" "$MM_TARBALL" | sha256sum -c -          # aborts on mismatch
tar -xjf "$MM_TARBALL" -C "$MM_DIR" bin/micromamba                   # single reviewed member
# (Kaggle images run as root, so /usr/local/bin is writable — verified v34–v56 and in the
Confidence
83% confidence
Finding
The skill bootstraps itself by fetching an executable artifact from an external domain at runtime. The SHA-256 check materially improves safety, but the pattern still expands the trust boundary to a network source and creates a supply-chain risk: if the fetched binary, release channel, or checksum source is subverted, the environment executes attacker-controlled tooling early in the workflow.

Static analysis

No suspicious patterns detected.