T08 · Insecure Dependencies
Warning
- Location
- scripts/ingest.py:67
- Finding
- Unverified sibling ontology module execution during ingestion<![CDATA[ ## Vulnerability Details **File Location**: `scripts/ingest.py`, lines 67–82 **Vulnerability Type**: Unverified local dependency loading **Risk Level**: Medium ### Vulnerable Code ```python _ONTOLOGY_SCRIPT = Path(__file__).resolve().parent.parent.parent / "ontology" / "scripts" / "ontology.py" if _ONTOLOGY_SCRIPT.exists(): sys.path.insert(0, str(_ONTOLOGY_SCRIPT.parent)) try: from ontology import ( load_graph, create_entity, create_relation, update_entity, append_op, generate_id, ) _ONTOLOGY_OK = True except ImportError: _ONTOLOGY_OK = False ``` ### Technical Analysis The ingestion script constructs a path to a separate sibling skill, adds that directory to the beginning of `sys.path`, and imports the `ontology` module solely because the expected file exists. Python executes a module's top-level code during import. Consequently, the imported sibling component receives code execution before the requested ingestion operation begins. The implementation does not validate the module's cryptographic digest, provenance, ownership, filesystem permissions, or trusted installation source. Because the directory is inserted at index zero in `sys.path`, it takes precedence over normal module search locations. A malicious or compromised sibling `ontology` skill can therefore supply attacker-controlled implementations or arbitrary import-time code. The script already contains local fallback graph functions, so execution of an external sibling module is not required for the core ingestion workflow. ### Attack Path 1. An attacker publishes or distributes a malicious skill under the sibling name `ontology`, or compromises an existing installation. 2. The malicious package places attacker-controlled code at `ontology/scripts/ontology.py`. 3. The victim installs that component alongside this skill. 4. The victim runs a documented command such as: ```bash python3 scripts/ingest.py scan ...[truncated 1180 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Remove the implicit sibling-module import and use the bundled fallback implementation unconditionally when possible. 2. If shared functionality is necessary, package it as an explicit, version-pinned dependency installed from a trusted source. 3. Verify the dependency with a cryptographic hash or signed package metadata before loading it. 4. Avoid inserting automatically discovered directories at the beginning of `sys.path`. 5. Require an explicit configuration option for any external ontology implementation. 6. Resolve and validate the configured path before import, including: - Ensuring it is inside an approved installation root. - Rejecting unexpected symbolic-link traversal. - Checking ownership and write permissions. - Rejecting files writable by untrusted users. 7. Prefer importing through standard package management rather than loading code based only on filesystem presence. 8. Run ingestion with minimal filesystem, environment, subprocess, and network privileges as defense in depth. ]]>