Skip to content

Security: Kesowa/vod-transcode

Security

SECURITY.md

Security Policy

Reporting a vulnerability

Please report security issues privately rather than opening a public issue.

Include what you did, what happened and what you expected, with enough detail to reproduce — for a transcoding bug, that usually means the characteristics of the input file. We will acknowledge your report and tell you whether we intend to fix it, and when.

Please only test against infrastructure you own.

Threat model

This is an internal worker process, not a public service. It listens on no port. Its inputs are:

  1. JSON job messages from a RabbitMQ queue, which is inside the trust boundary.
  2. Video files fetched from object storage, which are ultimately uploaded by users and are therefore untrusted.

The second is where the risk concentrates, and it is a sharp one: this worker hands attacker-influenced video to GStreamer, a large body of native code including demuxers and decoders written in C. A malformed container or stream is the realistic attack surface here, far more than anything in the Rust.

In scope

  • Memory safety or crash in the media path. A crafted video that causes a segfault, a heap overflow or an unbounded allocation inside the pipeline. If the root cause is in GStreamer itself, report upstream too, but we want to know how it reached us.
  • Denial of service through crafted input. A file that makes the pipeline hang forever occupies a worker permanently, and with prefetch 1 that is one fewer worker for everything else. A decompression-bomb equivalent — modest input producing enormous output — is also in scope.
  • Path traversal through the job key. Output paths are derived from the input key by taking its parent and file stem. A key that escapes the intended prefix, or overwrites an object it should not, is a real finding.
  • Writing outside the intended bucket or prefix, by any route.
  • Credential exposure — a credential reaching a log line, an error message, a response payload, or a GStreamer debug dump.
  • Unsafe handling of the job message, such as a field used to construct a pipeline description.
  • Vulnerable dependencies in Cargo.toml or Cargo.lock.

Out of scope

  • The minioadmin / minioadmin defaults in .env.example, entrypoint.sh and the credential fallbacks in main.rs. These are MinIO's published defaults for local development, not Kesowa credentials. We know they are there, and the risk of a silent fallback is documented in the README and CONTRIBUTING. A concrete path by which a production deployment reaches those defaults would be in scope.
  • The absence of authentication on a worker that has no listening socket.
  • entrypoint.sh generally. It is a debugging aid with hardcoded development values, not part of the deployed path.
  • Findings in GStreamer, RabbitMQ or MinIO themselves with no exploit path through this worker. Report those upstream — though for GStreamer we would still appreciate a heads-up, since it is our main attack surface.
  • expect() in startup configuration handling. Failing fast on invalid configuration is deliberate.
  • Transcoding bugs with no security impact — wrong aspect ratio, missing audio, a broken thumbnail. Open a normal issue.

Hardening notes for operators

  • Give each worker an object-store credential scoped to the one bucket it needs, not a root key. On AWS, prefer a role over a long-lived key.
  • Set resource limits. Transcoding is CPU and memory hungry, and a hostile input can make it more so. A memory limit turns a potential host-level incident into one failed job.
  • Workers trust the queue. Anyone who can publish to vod.transcode.req can point a worker at any object key the worker's credential can reach, so restrict who can publish.
  • Keep GStreamer patched. It is the largest body of untrusted-input-facing native code in this service, and the dependency most likely to need an urgent update.

There aren't any published security advisories