Skip to content

GHSA-xmp9-244p-5ggv

CVE Information

Summary

rsyslog's omfile dynaFile facility intentionally allows templates to generate flexible output paths. This supports valid deployments that route logs into different directories or use dynamically generated file names.

A deployment becomes unsafe when a dynaFile template uses a value influenced by untrusted input as a path component without explicit secure-path handling. In that configuration, the rendered path can escape the operator's intended log directory.

This is not limited to the RFC5424 HOSTNAME field. Any untrusted value that reaches a dynaFile path component can create the condition.

Impact

An attacker who can influence such a value may cause rsyslog to create or append to files outside the intended output directory, subject to rsyslog's effective privileges and host confinement.

The practical result depends on the deployment. Mandatory access controls, systemd sandboxing, filesystem permissions, the configured input modules, and the selected output template can all limit or prevent impact. A code-execution outcome requires additional, deployment-specific conditions and is not representative of default distribution configurations.

Default Debian and Ubuntu configurations do not enable a network input and a dynaFile action of this form. The affected configuration must be explicitly deployed.

Affected configurations

The condition requires all of the following:

  • An omfile action using dynaFile.
  • A template that incorporates attacker-controlled or otherwise untrusted input into a path component.
  • No explicit securepath, secpath-drop, or secpath-replace handling for that input.
  • An attacker who can influence the relevant input.
  • Effective rsyslog privileges and host confinement that permit a write outside the intended directory.

Affected versions

rsyslog versions beginning with 1.15.0 include the flexible dynaFile behavior and can be affected when configured as described above.

No version is currently listed as fully patched. A fixed release will be recorded here when the containment work is released.

Mitigation

Explicit secure-path handling has always been the documented and recommended way to use untrusted values in dynaFile paths.

The primary action for operators is to apply explicit secure-path handling to every untrusted value used by a dynaFile template. Use securepath, secpath-drop, or secpath-replace, as appropriate for the intended naming scheme.

rsyslog 8.2606.0 introduced compatibility secure-default modes to support this migration:

  • global(compatibility.defaults.secure="warn") preserves the historical behavior but emits startup warnings for affected dynaFile templates.
  • global(compatibility.defaults.secure="strict") defaults fields without explicit secure-path handling to secpath-replace.
  • global(compatibility.defaults.secure="backward-compatible") preserves the historical behavior silently. This remains the default to avoid breaking existing configurations that intentionally depend on flexible path generation.

Operators should use warn, the default, to identify templates needing review, then add explicit secure-path handling or adopt strict where compatible Strict automatically sets the secure defaults. These explicit options are the reliable way to define which input may become part of a path.

Run rsyslog with the least privileges needed and retain appropriate operating-system confinement. These controls reduce impact but do not replace secure template design.

Compatibility and remediation status

The historical flexibility of dynaFile is intentional and remains supported. An unconditional rejection of generated paths, or an automatic path rewrite, would break valid existing configurations, including deployments that intentionally write to multiple locations.

To still provide better security against malicious data, the patch implements a filesystem sandbox, which makes best effort to prevent escaping the configured constant filesystem prefix. rsyslog does not claim that dynaFile provides a complete filesystem sandbox. Reliably enforcing one across symlinks, bind mounts, races, and platform-specific filesystem behavior is substantially more complex; similar containment approaches have proven difficult to make dependable.

Accordingly, the remediation focuses on preserving compatibility while making unsafe templates visible and providing a reliable secure configuration path. Operators should apply the secure-path options above rather than relying on implicit filesystem containment. The actual operator recommended option is to either use explicit escaping or run in "strict" security mode when the functionality is not needed.

CVSS

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H (8.1 High)

This score reflects a network-reachable deployment with the required unsafe configuration and sufficient process privileges. It does not imply that default rsyslog or distribution configurations are affected.

Credit

Thanks to @mikecole-mg for reporting this issue and for the constructive discussion. The same thanks to @mat-mo who reported this independently a bit later.

A CVE has been requested through GitHub and is pending; CVE assignment will not delay publication.