Subject: Adding accounts for just the system account adds auth bypass

NATS-advisory-ID: 2023-01
Aliases: CVE-2023-47090, GHSA-fr2g-9hjm-wr23, GO-2023-2133
Date: 2023-10-12
Fixed-In: nats-server 2.9.23, 2.10.2

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 users exist within accounts, and once using accounts, the old
authorization block is not applicable.


Problem Description:

Without any authorization rules in the nats-server, users can connect
without authentication.  This is expected and fine.

Before nats-server 2.2.0, all authentication and authorization rules for
a nats-server lived in an "authorization" block, defining users.  With
nats-server 2.2.0 all users live inside accounts.  When using the
authorization block, whose syntax predates this, those users will be
placed into the implicit global account, "$G".  Users inside accounts go
into the newer "accounts" block.

If an "accounts" block is defined, in simple deployment scenarios this
is often used only to enable client access to the system account.  When
the only account added is the system account "$SYS", the nats-server
would create an implicit user in "$G" and set it as the `no_auth_user`
account, enabling the same "without authentication" logic as without
any rules.

This preserved the ability to connect simply, and then add one
authenticated login for system access.

But with an "authorization" block, this is wrong.  Users exist in the
global account, with login rules.  And in simple testing, they might
still connect fine without administrators seeing that authentication has
been disabled.

The blind-spot on our part came from encouraging and documenting a
switch to using only "accounts", instead of "authorization".

In the fixed versions, using an "authorization" block will inhibit the
implicit creation of a "$G" user and setting it as the `no_auth_user`
target.  In unfixed versions, just creating a second account, with no
users, will also inhibit this behavior.


Affected versions:

NATS Server:
 * 2.2.0 up to and including 2.9.22 and 2.10.1
 * Fixed with nats-io/nats-server: 2.10.2 and backported to 2.9.23


Workarounds:

In the "accounts" block, define a second non-system account, leave
it empty.

    accounts {
        SYS: {
            users: [
                { user: sysuser, password: makemeasandwich }
            ]
        }
        DUMMY: {}  # for security, before 2.10.2
    }
    system_account: SYS


Solution:

Any one of these:

 1. Upgrade the NATS server to at least 2.10.2 (or 2.9.23)
 2. Or define a dummy account
 3. Or complete the migration of authorization entries to be inside
    a named account in the "accounts" block


Credits:

Problem reported by Alex Herrington.
Addressed publicly in a GitHub Discussion prior to this advisory.


References:

* GitHub Security Advisory for nats-server:
  <https://github.com/nats-io/nats-server/security/advisories/GHSA-fr2g-9hjm-wr23>
* Go Vulnerability Report: GO-2023-2133:
  <https://pkg.go.dev/vuln/GO-2023-2133>