Containment Under Hostile Input: Measuring Isolation in File Conversion Workloads

Abstract

Converting a file means opening data that someone else created, and parsing untrusted input is one of the most reliable ways to provoke unexpected behaviour in software. We evaluated how a conversion workload behaves when it is treated as inherently untrusted and confined accordingly. Against a synthetic adversarial corpus of 12,400 crafted inputs spanning malformed documents, decompression bombs, deeply nested structures, oversized media, and files that attempt to reach external resources, every job either produced a valid result or failed inside its own boundary. We observed zero sandbox escapes, zero impact on neighbouring jobs, and zero successful network egress. This study formalises the containment model behind PrivConvert.

Background

A file converter is, by definition, a program that reads input it did not produce. Documents, images, archives, and e-books are not passive data; they are richly structured formats with parsers, decoders, embedded references, and layout engines behind them. A maliciously crafted file can try to trigger excessive memory use, push a decoder into a pathological state, or coax a converter into fetching something from the network on the attacker's behalf.

The conventional answer is to harden the parser: patch bugs as they are found, add input checks, and hope the next malformed file does not find a gap. That approach is necessary but never sufficient, because the input space of real-world file formats is effectively unbounded. The more durable answer is to assume the parser will eventually misbehave and to ensure that when it does, the blast radius is a single, disposable job - not the host, not other users, and not the network.

This study asks a focused question: when a conversion is confined and then fed deliberately hostile input, does the confinement hold?

The Challenge

A general-purpose conversion service has to accept a wide range of formats, which means it carries a wide attack surface. We grouped the threats we wanted to contain into five families:

• Malformed and truncated documents - files whose internal structure is broken in ways designed to confuse a parser or drive it down an error path that was never meant to be reached.
• Decompression bombs - small inputs that expand to enormous sizes once decoded, aiming to exhaust memory or disk.
• Deeply nested and recursive structures - archives within archives, or document trees nested far beyond any legitimate need, intended to drive unbounded recursion.
• Oversized and high-resolution media - inputs whose declared dimensions or pixel counts are large enough to provoke runaway allocation.
• Embedded external references - files that instruct the converter to fetch a remote resource, the classic vehicle for turning a converter into a request proxy.

For each family, the question is not only “does the converter reject it” but “if the converter is pushed past its limits, does the failure stay where it started.”

Our Approach

We treat every conversion as a self-contained, throwaway unit of work. Each job runs inside its own isolated environment with three properties enforced from the outside rather than requested politely from within:

• No network path. A conversion has no legitimate reason to reach the internet, so the environment provides no route to it. A file that asks the converter to fetch something simply finds nowhere to send the request.
• Bounded resources. Each job runs under fixed ceilings. A job that tries to consume more than its share is stopped, and the stop is scoped to that job alone.
• Ephemeral, private state. A job cannot see, read, or influence any other job. When it ends - successfully or not - its working state is discarded.

The corpus was generated synthetically and run through this confinement in repeated batches, including concurrent batches designed to look for interference between simultaneous jobs. We measured four outcomes per input: whether it was handled cleanly (converted or rejected with a defined error), whether it escaped its environment, whether it affected any other job, and whether it managed to reach the network.

Results

We ran all 12,400 inputs through the confinement, in both sequential and concurrent configurations. For every family of hostile input, the result was the same: the job was handled inside its own boundary, nothing escaped, nothing touched a neighbour, and nothing reached the network.

Containment by Input Family

Input Family	Samples	Contained	Escapes	Cross-job	Reached Net
Malformed / truncated documents	3,200	100%	0	0	0
Decompression bombs	2,600	100%	0	0	0
Deeply nested / recursive	1,900	100%	0	0	0
Oversized / high-resolution media	1,800	100%	0	0	0
Embedded external references	1,500	100%	0	0	0 / 1,500 blocked
Encoding / parser edge cases	1,400	100%	0	0	0

Behaviour Under Concurrency

Containment is easy to demonstrate one job at a time; the interesting test is what happens when many jobs run together and one of them misbehaves. We interleaved hostile inputs with ordinary conversions under sustained concurrent load and watched for interference: a failing job slowing down its neighbours, leaking state into them, or causing a wider stall.

Across the concurrent batches, a job exceeding its limits failed on its own and returned a defined error. Neighbouring conversions completed normally, and throughput degraded gracefully rather than collapsing. Failures were deterministic - the same hostile input produced the same contained outcome on every run - which is the property that lets us reason about the system instead of hoping.

Implications for PrivConvert

This containment model is the foundation of how PrivConvert handles every file. Because each conversion is treated as untrusted and confined from the outside, a malicious upload has nowhere useful to go: it cannot reach your data, anyone else's data, the host, or the network, and the moment the job ends its state is discarded. That is what lets PrivConvert offer conversion without storing your files and without asking you to trust that the converter is bug-free.

For a plain-language walk-through of the same ideas, see our blog post Secure by Design: How PrivConvert Isolates Every File Conversion.

Limitations

This study measures containment, not the absence of bugs. A parser flaw can still cause an individual conversion to fail; the claim we test is that such a failure stays inside one disposable job. The corpus is synthetic and, like any adversarial corpus, cannot be exhaustive - the input space of real file formats has no fixed boundary. We treat containment as a property to be continuously re-tested as formats and tooling evolve, not as a result that is proven once. Finally, this work concerns isolation behaviour only; it does not address every layer of the wider security posture, which is evaluated separately.