T03 · Remote Payload Retrieval and Execution
Error
- Location
- scripts/setup.sh:103
- Finding
- Unverified Remote JAR Download and Execution## Vulnerability Details **File Location**: `scripts/setup.sh:103-126`, `scripts/setup.sh:202-225`, and `scripts/defense-smart.sh:317` **Vulnerability Type**: Unverified remote payload retrieval and execution **Risk Level**: High ```bash if command -v curl &> /dev/null; then log_info "Using curl to download..." if curl -L -o "$TOOL_ZIP" "$TOOL_URL"; then log_success "Tool downloaded successfully!" return 0 else log_error "Download with curl failed" rm -f "$TOOL_ZIP" fi fi if command -v wget &> /dev/null; then log_info "Using wget to download..." if wget -O "$TOOL_ZIP" "$TOOL_URL"; then log_success "Tool downloaded successfully!" return 0 else log_error "Download with wget failed" rm -f "$TOOL_ZIP" fi fi ``` The downloaded JAR is validated only by size and archive format: ```bash file_size=$(stat -f%z "$TOOL_JAR" 2>/dev/null || stat -c%s "$TOOL_JAR" 2>/dev/null) if [ "$file_size" -lt 102400 ]; then log_error "Tool file size is abnormal and may be incomplete" log_info "File size: $file_size bytes" exit 1 fi if ! file "$TOOL_JAR" | grep -q "Java archive\|Zip archive"; then log_error "Invalid tool format; the file is not a valid JAR" exit 1 fi ``` It is subsequently executed: ```bash if java -jar "$TOOL_JAR" "${params_array[@]}" -input "$file" -output "$output_file" 2>&1 | tee "$LOG_FILE"; then ``` ### Technical Analysis The setup process retrieves a mutable executable archive from an external endpoint and follows HTTP redirects through `curl -L`. It does not verify a pinned cryptographic digest, package signature, signing certificate, or trusted release manifest. A size threshold and archive-format check establish only that the file resembles a JAR or ZIP. They provide no assurance that the payload was published by the expecte ...[truncated 1607 chars]
- Remediation
- ## Remediation Suggestions 1. Publish a SHA-256 or stronger digest through a separately authenticated release channel and verify it before extraction. 2. Prefer a digitally signed release manifest or signed JAR, and validate the signature against a pinned vendor public key. 3. Pin a specific tool version rather than downloading a mutable latest release. 4. Restrict redirects to an explicit allowlist, or reject cross-origin redirects entirely. 5. Download into a private temporary directory created with `mktemp -d` and restrictive permissions. 6. Abort and delete the archive and extracted files on any integrity-verification failure. 7. Verify every executable component extracted from the archive, not only the primary JAR. 8. Run the third-party tool in a sandbox or isolated container with minimal filesystem access, no unnecessary credentials, and restricted network access. 9. Do not describe file size and format checks as integrity verification; they should only be supplemental validation.