Preface: The payment systems based on a distributed architecture will be enhanced efficient and scalable. Therefore, distributed ledger technology (DLT) will become a trend in future. The DLT Pilot Regime defines “tokenization of financial instruments” as a process that involves the conversion of traditional financial asset classes into digital tokens that can be stored, transferred and traded on distributed ledgers. Apart from DLT, there is other option in the market. NATS makes it easy for applications to communicate by sending and receiving messages. These messages are addressed and identified by subject strings, and do not depend on network location. Data is encoded and framed as a message will be sent by a sender (original destination).

Background: NATS.io is a high performance open source pub-sub distributed communication technology, built for the cloud, on-premise, IoT, and edge computing. The cryptographic key handling library, nkeys, recently gained support for encryption, not just for signing/authentication. This is used in nats-server 2.10 (Sep 2023) and newer for authentication callouts. Vulnerability details: The nkeys library’s “xkeys” encryption handling logic mistakenly passed an array by value into an internal function, where the function mutated that buffer to populate the encryption key to use.  As a result, all encryption was actually to an all-zeros key. This affects encryption only, not signing.

Within the nats-server, the encryption is used for the Auth Callouts feature, introduced with 2.10.0 (September 2023). The Auth Callout request includes the supplied user password. These messages are sent within NATS, and should typically be in a dedicated NATS Account used for callouts, but this is not required. Thus in scenarios where the Callouts are in an account shared with untrusted users or where the callout responders connect without TLS, this may lead to user credential exposure.

Affected versions:

nkeys Go library:

 * 0.4.0 up to and including 0.4.5

 * Fixed with nats-io/nkeys: 0.4.6

NATS Server:

 * 2.10.0 up to and including 2.10.3

 * Fixed with nats-io/nats-server: 2.10.4

Official announcement: Please refer to the link for details – https://advisories.nats.io/CVE/secnote-2023-02.txt

Preface: Government agencies and companies in emerging tech, finance, healthcare, and other industries use Red Hat® products and services. OpenShift gives organizations the ability to build, deploy, and scale applications faster both on-premises and in the cloud. It also protects your development infrastructure at scale with enterprise-grade security.

Background: Skupper is a layer 7 service interconnect. It enables secure communication across Kubernetes clusters with no VPNs or special firewall rules. With Skupper, your application can span multiple cloud providers, data centers, and regions. The Skupper Operator creates and manages Application Interconnect sites in Kubernetes. Skupper operator that simply produces the bundle and the index images. Its goal is to avoid introducing a new CRD, just relying on the site-controller to kick things off based on an existing skupper-site ConfigMap.

Ref: The primary grouping concept in Kubernetes is the namespace. Namespaces are also a way to divide cluster resources between multiple uses. That being said, there is no security between namespaces in Kubernetes; if you are a “user” in a Kubernetes cluster, you can see all the different namespaces and the resources defined in them.

Vulnerability details: A flaw was found in the Skupper operator, which may permit a certain configuration to create a service account that would allow an authenticated attacker in the adjacent cluster to view deployments in all namespaces in the cluster. This issue permits unauthorized viewing of information outside of the user’s purview.

Additional: If the skupper operator is running and a user in a given namespace creates a ConfigMap with the name skupper-site and includes in the data the line, `cluster-permissions: “true”`, then the operator will  create a service account in that namespace that has cluster permissions enabling it to watch deployments in all namespaces on the cluster. This is the case even if the user creating that ConfigMap does not themselves have access to other namespaces.

Official announcement: Please refer to the link for details – https://access.redhat.com/errata/RHSA-2023:6219