Skip to content

CWE-514: Covert Channel

Overview

A covert channel is any path a program uses to transfer information in a way its designers didn't intend, usually by encoding data in a side effect - timing, resource usage, shared state - rather than through a sanctioned output. This is a general category. Almost every finding that lands here is really one of its two children, timing-based or storage-based.

Relationship to Other CWEs

CWE-514 has two children. CWE-385 (Covert Timing Channel) covers information leaked through observable execution-time differences, such as a password check that returns faster for a wrong username than for a wrong password. CWE-515 (Covert Storage Channel) covers information leaked by writing to a shared resource another party can observe: a file's existence, a cache entry, a shared counter. Map a timing finding to CWE-385 and follow that page. Map a storage or shared-state finding to CWE-515; there is no CWE-515 page here yet, so the remediation to use is the storage material below. Map to CWE-514 itself only when the channel is neither.

Risk

Medium-High: Impact depends on what the channel leaks and to whom, from low-value reconnaissance up to full secret recovery. CWE-385 covers the most common case, credential and key extraction through response-time analysis.

Remediation Steps

Core Principle: Any output a program produces - including side effects like timing, resource usage, or shared state - should not vary based on secret data in a way an unauthorized party can observe.

Identify the Specific Channel

Work out which mechanism carries the leak before choosing a fix:

  • Timing: Does the operation's duration vary with secret data? CWE-385 has the remediation path - constant-time comparison and equalized code paths.
  • Storage/shared state: Does the program's effect on a shared resource - a file, a cache, a counter, an error log - reveal information to a party that shouldn't have access to it? The tell is that the observer never reads the secret, only something whose state depends on it: whether a temporary file exists, whether a username appears in a cache, whether a counter moved.
  • Resource usage: Does memory, CPU, or bandwidth consumption leak information on its own, such as a compression ratio revealing plaintext content in CRIME/BREACH-style attacks?

Eliminate or Equalize the Observable Difference

Whichever channel it is, the fix has the same shape: make the observable side effect independent of the secret. For timing, that means constant-time operations. For resource usage, pad or normalize the output size.

For storage and shared state, there are three moves, in order of preference. Remove the shared resource from the path, so there is nothing to observe - a per-request temporary file named unpredictably and deleted on every exit leaks nothing, where a well-known path whose existence tracks a secret leaks a bit per request. Where the resource has to be shared, make the write unconditional: touch the file, increment the counter, or populate the cache entry on every outcome rather than only on the interesting one, so its state stops correlating with the secret. Where neither is possible, put an access control between the resource and the observer - directory permissions, a namespace, a per-tenant cache key - so the channel still exists but nobody unauthorized is on the receiving end. That last one is containment rather than a fix, and it fails the moment the boundary moves.

Restrict Who Can Observe the Channel

Where the side effect can't be equalized, reduce who can observe it. Keep fine-grained timing and resource metrics away from untrusted callers, including debug endpoints, verbose logs, and detailed error responses. Rate-limit the operation so an attacker can't collect enough samples to exploit what remains statistically.

Test the Fix

  • Identify the specific observable signal (timing, a file's presence, a log entry, response size) and verify it no longer correlates with the secret value across many trials
  • Re-scan with the security scanner to confirm the finding is resolved

Additional Resources