Subject: Arbitrary file write from the privileged system account

NATS-advisory-ID: 2022-03
CVE: CVE-2022-28357
Date: 2022-04-18
Fixed-In: nats-server 2.8.0; nats-streaming-server 0.24.3

Background:

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

NATS supports multiple accounts, each with users, and each account
being a namespace for streams.  One of the special accounts is the
system account, $SYS, which is privileged.


Problem Description:

There is an inadequate check in constructing filenames for account
synchronization, which happens in the system account, allowing
arbitrary file write as the user running NATS by anyone who can publish
arbitrary messages to the system account.

Note that the security model of NATS is that the system account is
privileged and allowed to perform various administrative actions;
we view this as a "superuser" access path, with future work being
allowed to expand upon the administrative actions which can be
performed by a client connected into this account.

As such, CVE-2022-28357 is an unexpected write to an arbitrary file
but does not cross a privilege boundary.  We opted to request a CVE
for this anyway, so that we can draw attention to this aspect of the
security model and help administrators make an informed decision about
how to run and constrain a NATS server.

Note that within a cluster or super-cluster, the system account is
shared, allowing for lateral movement by an attacker within such a
deployment.


Affected versions:

NATS Server:
 * 2.2.0 up to and including 2.7.4.
 * Fixed with nats-io/nats-server: 2.8.0
 * Docker image:  nats <https://hub.docker.com/_/nats>

NATS Streaming Server
 * 0.15.0 up to and including 0.24.3
 * Fixed with nats-io/nats-streaming-server: 0.24.4


Workarounds:

We recommend that the nats-server be sandboxed so that the only areas
of the filesystem which it can write to are those which the
administrators expect it to be able to write to.  We recommend running
the nats-server as a dedicated user.

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, with a ReadWritePaths hole for the expected writable
areas.


Solution:

Upgrade the NATS server to at least 2.8.0.

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


Credits:

This issue was discovered by Gerardo Iglesias and Victor Mata,
of Accenture Security.  Thank you!


References:

 * This document is canonically:
   <https://advisories.nats.io/CVE/CVE-2022-28357.txt>
 * MITRE CVE entry:
   <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-28357>