Skip to content

Arbitrary file write in nats-server

High severity GitHub Reviewed Published Mar 10, 2022 in nats-io/nats-server • Updated Feb 3, 2023

Package

gomod github.com/nats-io/nats-server/v2 (Go)

Affected versions

>= 2.2.0, < 2.7.4

Patched versions

2.7.4
gomod github.com/nats-io/nats-streaming-server (Go)
>= 0.15.0, < 0.24.3
0.24.3

Description

(This document is canonically: https://advisories.nats.io/CVE/CVE-2022-26652.txt)

Background

NATS.io is a high performance open source pub-sub distributed communication technology, built for the cloud, on-premise, IoT, and edge computing.

JetStream is the optional RAFT-based resilient persistent feature of NATS.

Problem Description

The JetStream streams can be backed up and restored via NATS. The backup format is a tar archive file. Inadequate checks on the filenames within the archive file permit a so-called "Zip Slip" attack in the stream restore.

NATS nats-server through 2022-03-09 (fixed in release 2.7.4) did not correctly sanitize elements of the archive file, thus a user of NATS
could cause the NATS server to write arbitrary content to an attacker-controlled filename.

Affected versions

NATS Server:

  • 2.2.0 up to and including 2.7.3.
    • Introduced with JetStream Restore functionality
  • Fixed with nats-io/nats-server: 2.7.4
  • Docker image: nats https://hub.docker.com/_/nats
  • NB users of OS package files from our releases: a change in goreleaser defaults, discovered late in the release process, moved the install directory from /usr/local/bin to /usr/bin; we are evaluating the correct solution for subsequent releases, but not recutting this release.

NATS Streaming Server

  • 0.15.0 up to and including 0.24.2
  • Fixed with nats-io/nats-streaming-server: 0.24.3
  • Embeds a nats-server, but this server is the old approach which JetStream replaces, so unlikely (but not impossible) to be
    configured with JS support

Workarounds

  • Disable JetStream for untrusted users.
  • If only one NATS account uses JetStream, such that cross-user attacks are not an issue, and any user in that account with access to the JetStream API is fully trusted anyway, then appropriate sandboxing techniques will prevent exploit.
    • Eg, with systemd, the supplied util/nats-server-hardened.service example configuration demonstrates that NATS runs fine as an unprivileged user under ProtectSystem=strict and PrivateTmp=true restrictions; by only opening a ReadWritePaths hole for the JetStream storage area, the impact of this vulnerability is limited.

Solution

Upgrade the NATS server to at least 2.7.4.

We fully support the util/nats-server-hardened.service configuration for running a NATS server and encourage this approach.

Credits

This issue was reported (on 2022-03-07) to the NATS Maintainers by
Yiming Xiang, TIANJI LAB of NSFOCUS.
Thank you / 谢谢你!

References

@philpennock philpennock published to nats-io/nats-server Mar 10, 2022
Published by the National Vulnerability Database Mar 10, 2022
Published to the GitHub Advisory Database Mar 10, 2022
Reviewed Mar 10, 2022
Last updated Feb 3, 2023

Severity

High

Weaknesses

CVE ID

CVE-2022-26652

GHSA ID

GHSA-6h3m-36w8-hv68

Source code

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.