ClawHub
Back to skill

Security audit

Timestamp

Security checks for vulnerabilities and agentic risk

Overview

This skill is a coherent OpenTimestamps helper that submits file hashes, creates local proof files, and verifies them, with no evidence of hidden execution or persistence.

Install the OpenTimestamps client in an isolated, preferably pinned environment. Before using auto-memory mode, review the target file list, including `USER.md`. Do not timestamp highly sensitive or easily guessable files unless you accept that their hashes and timing metadata may be sent to third-party timestamp infrastructure.

A.I.G

Vulnerability Patterns
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • 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
Findings (2)

T08 · Insecure Dependencies

Warning
Location
SKILL.md:104
Finding

Unpinned Third-Party Dependency Installation

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, line 104
Vulnerability Type: Unpinned package installation from a third-party package repository
Risk Level: Medium

Vulnerable Code

bash
pip3 install opentimestamps-client

Technical Analysis

The documented installation command retrieves and installs whichever version of opentimestamps-client the package index currently resolves as the latest release. It does not specify a reviewed version, validate an artifact hash, enforce a lock file, or explicitly identify a trusted package index.

Python packages can execute code during installation and subsequently when their commands or modules are invoked. Consequently, the effective code installed by this instruction can change after the Skill has been reviewed. Exploitation would require compromise of the legitimate package, its publisher account, the configured package repository, or the dependency-resolution path. The audit found no evidence that the package currently contains malicious code; the confirmed weakness is the absence of dependency pinning and integrity verification.

Attack Path

  1. An attacker compromises the package publisher, package repository, or another relevant dependency-distribution component.
  2. The attacker publishes a malicious release that resolves under the unversioned package name.
  3. A user follows the setup documentation and runs pip3 install opentimestamps-client.
  4. pip downloads and installs the attacker-controlled release without checking a project-supplied expected version or hash.
  5. Malicious code executes during installation or when the installed ots command is subsequently used.

Impact Assessment

Malicious package code could execute with the privileges of the user running pip3. Depending on those privileges and the local Python installation configuration, this could permit access to user-readable files, modification of user-owned data, theft o ...[truncated 396 chars]

Remediation
View remediation

Remediation Suggestions

  • Pin opentimestamps-client to a specifically reviewed version.
  • Distribute a dependency lock file containing cryptographic hashes and install with pip --require-hashes.
  • Explicitly specify the approved package index and prevent fallback to untrusted indexes.
  • Review and pin transitive dependencies as well as the direct dependency.
  • Prefer an isolated virtual environment rather than installation into a shared or privileged Python environment.
  • Document a controlled upgrade process that reviews new versions before updating the pin.

Example hardened installation pattern:

bash
python3 -m venv .venv
.venv/bin/python -m pip install --require-hashes -r requirements.lock

The lock file should contain an exact version and approved hashes for every resolved package.

T09 · Insecure Skill Coding Practices

Note
Location
scripts/ots-stamp.sh:34
Finding

Timestamp Archive Name Collision Can Overwrite Existing Proofs

Content
View full analysis

Vulnerability Details

File Location: scripts/ots-stamp.sh, lines 34-40
Vulnerability Type: Unsafe archive collision handling
Risk Level: Low

Vulnerable Code

bash
if [ -f "$ots_file" ]; then
    archive_dir="$(dirname "$file")/.ots-archive/$(basename "$file")"
    mkdir -p "$archive_dir"
    timestamp=$(date -r "$ots_file" +%Y-%m-%d-%H%M%S 2>/dev/null || date +%Y-%m-%d-%H%M%S)
    mv "$ots_file" "$archive_dir/$timestamp.ots"
    echo "  (archived old proof: $archive_dir/$timestamp.ots)"
fi

Technical Analysis

Archived proof names are derived only from the existing proof file's modification time with one-second resolution. The script does not test whether the destination already exists before invoking mv.

Standard mv behavior permits an existing destination file to be replaced. Therefore, two proofs with the same derived timestamp can map to the same archive path, causing a previously archived proof to be silently overwritten. A collision can occur through repeated processing with matching timestamps, copied files that preserve modification times, restoration from backups, or deliberate modification of the proof file's timestamp by an actor who can write within the workspace.

This defect undermines the stated objective of maintaining a complete verifiable history. It does not forge a valid OpenTimestamps proof, but it can remove an older proof from the local archive.

Attack Path

  1. A proof already exists at .ots-archive/<filename>/YYYY-MM-DD-HHMMSS.ots.
  2. Another current .ots proof is assigned or retains a modification time that resolves to the same second.
  3. The protected source file changes and ots-stamp.sh runs again.
  4. The script derives the already-used archive destination name.
  5. mv replaces the existing archived proof without explicit collision detection.
  6. The previously stored historical proof is lost unless another backup or version-control c ...[truncated 692 chars]
Remediation
View remediation

Remediation Suggestions

  • Refuse to overwrite an existing archive by using mv -n and checking its result, or perform an explicit destination-existence check.
  • Generate collision-resistant archive names using nanosecond precision where supported and append a cryptographic digest or unique counter.
  • Create the destination atomically to avoid time-of-check/time-of-use races.
  • Treat archive collisions as errors and retain the current proof until a unique destination is secured.
  • Keep archived proofs in version control or an independently backed-up, append-only location.

Example collision-resistant approach:

bash
proof_hash="$(sha256sum "$ots_file" | awk '{print $1}')"
timestamp="$(date -r "$ots_file" +%Y-%m-%d-%H%M%S 2>/dev/null || date +%Y-%m-%d-%H%M%S)"
destination="$archive_dir/${timestamp}-${proof_hash}.ots"

if [ -e "$destination" ]; then
    echo "FAIL: archive destination already exists: $destination" >&2
    exit 1
fi

mv -n -- "$ots_file" "$destination"

The implementation should also verify that the move succeeded before reporting that the proof was archived.

SkillSpector

Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • 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
Findings (1)

Missing User Warnings

Low
Category
Not specified by scanner
Confidence
93% confidence
Finding

The skill encourages users to submit file-derived SHA-256 hashes to external OpenTimestamps calendar servers and later depend on external network/blockchain verification, but it does not clearly warn about that outbound data flow at the point of use. Even though hashes are less sensitive than raw files, they can still disclose existence, enable correlation/linkability, and create privacy surprises for users who assume the workflow is fully local.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.