Red Hat Security Advisory 2024-2628-03 - An update for kernel-rt is now available for Red Hat Enterprise Linux 9.2 Extended Update Support.

    The following advisory data is extracted from:https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_2628.jsonRed Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.- Packet Storm Staff====================================================================Red Hat Security AdvisorySynopsis:           Moderate: kernel-rt security and bug fix updateAdvisory ID:        RHSA-2024:2628-03Product:            Red Hat Enterprise LinuxAdvisory URL:       https://access.redhat.com/errata/RHSA-2024:2628Issue date:         2024-05-01Revision:           03CVE Names:          CVE-2024-25742====================================================================Summary: An update for kernel-rt is now available for Red Hat Enterprise Linux 9.2 Extended Update Support.Red Hat Product Security has rated this update as having a security impact of Moderate. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.Description:The kernel-rt packages provide the Real Time Linux Kernel, which enables fine-tuning for systems with extremely high determinism requirements.Security Fix(es):* CVE-2024-25743 hw: amd: Instruction raise #VC exception at exit (AMD-SN-3008,CVE-2024-25742,CVE-2024-25743)Bug Fix(es):* kernel-rt: update RT source tree to the latest RHEL-9.2 ad hoc schedule build (JIRA:RHEL-32985)Solution:https://access.redhat.com/articles/11258CVEs:CVE-2024-25742References:https://access.redhat.com/security/updates/classification/#moderatehttps://bugzilla.redhat.com/show_bug.cgi?id=2270836

Red Hat Security Advisory 2024-2628-03

Red Hat Security Advisory 2024-2627-03 - An update for kernel is now available for Red Hat Enterprise Linux 9.2 Extended Update Support.

The following advisory data is extracted from:

https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_2627.json

Red Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.

- Packet Storm Staff

====================================================================  
Red Hat Security Advisory

Synopsis:           Moderate: kernel security and bug fix update  
Advisory ID:        RHSA-2024:2627-03  
Product:            Red Hat Enterprise Linux  
Advisory URL:       https://access.redhat.com/errata/RHSA-2024:2627  
Issue date:         2024-05-01  
Revision:           03  
CVE Names:          CVE-2024-25742  
====================================================================

Summary: 

An update for kernel is now available for Red Hat Enterprise Linux 9.2 Extended Update Support.

Red Hat Product Security has rated this update as having a security impact of Moderate. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.

Description:

The kernel packages contain the Linux kernel, the core of any Linux operating system.

Security Fix(es):

* CVE-2024-25743 hw: amd: Instruction raise #VC exception at exit (AMD-SN-3008,CVE-2024-25742,CVE-2024-25743)

Bug Fix(es):

* CVE-2024-25743 kernel: hw: amd: Instruction raise #VC exception at exit (JIRA:RHEL-30028)

* Seeing high latency execution of kernel functions associated with cgroup_rstat_updated() (JIRA:RHEL-30186)

* RHEL9 NFS file corruption handling congestion (JIRA:RHEL-31223)

* Add tracepoints for sources of IPIs (JIRA:RHEL-27097)

* In RHEL9/cgroupv2, vhost task is not pinned to pCPU defined by emulatorpin (JIRA:RHEL-32635)

Solution:

https://access.redhat.com/articles/11258

CVEs:

CVE-2024-25742

References:

https://access.redhat.com/security/updates/classification/#moderate  
https://bugzilla.redhat.com/show_bug.cgi?id=2270836

Red Hat Security Advisory 2024-2627-03

Red Hat Security Advisory 2024-2005-03 - An update for linux-firmware is now available for Red Hat Enterprise Linux 8.2 Advanced Update Support, Red Hat Enterprise Linux 8.2 Telecommunications Update Service, and Red Hat Enterprise Linux 8.2 Update Services for SAP Solutions. Issues addressed include an information leakage vulnerability.

    The following advisory data is extracted from:https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_2005.jsonRed Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.- Packet Storm Staff====================================================================Red Hat Security AdvisorySynopsis:           Moderate: linux-firmware security updateAdvisory ID:        RHSA-2024:2005-03Product:            Red Hat Enterprise LinuxAdvisory URL:       https://access.redhat.com/errata/RHSA-2024:2005Issue date:         2024-04-23Revision:           03CVE Names:          CVE-2023-20569====================================================================Summary: An update for linux-firmware is now available for Red Hat Enterprise Linux 8.2 Advanced Update Support, Red Hat Enterprise Linux 8.2 Telecommunications Update Service, and Red Hat Enterprise Linux 8.2 Update Services for SAP Solutions.Red Hat Product Security has rated this update as having a security impact of Moderate. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.Description:The linux-firmware packages contain all of the firmware files that are required by various devices to operate.Security Fix(es):* hw amd: Return Address Predictor vulnerability leading to information disclosure (CVE-2023-20569)For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.Solution:https://access.redhat.com/articles/11258CVEs:CVE-2023-20569References:https://access.redhat.com/security/updates/classification/#moderatehttps://bugzilla.redhat.com/show_bug.cgi?id=2207625

Red Hat Security Advisory 2024-2005-03

Red Hat Security Advisory 2024-1877-03 - An update for kernel is now available for Red Hat Enterprise Linux 8.6 Extended Update Support. Issues addressed include denial of service, information leakage, null pointer, and use-after-free vulnerabilities.

The following advisory data is extracted from:

https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_1877.json

Red Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.

- Packet Storm Staff

====================================================================  
Red Hat Security Advisory

Synopsis:           Moderate: kernel security and bug fix update  
Advisory ID:        RHSA-2024:1877-03  
Product:            Red Hat Enterprise Linux  
Advisory URL:       https://access.redhat.com/errata/RHSA-2024:1877  
Issue date:         2024-04-18  
Revision:           03  
CVE Names:          CVE-2021-26341  
====================================================================

Summary: 

An update for kernel is now available for Red Hat Enterprise Linux 8.6 Extended Update Support.

Red Hat Product Security has rated this update as having a security impact of Moderate. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.

Description:

The kernel packages contain the Linux kernel, the core of any Linux operating system.

Security Fix(es):

* hw: cpu: AMD CPUs may transiently execute beyond unconditional direct branch (CVE-2021-26341)

* kernel: use-after-free and memory errors in ext4 when mounting and operating on a corrupted image (CVE-2022-1184)

* kernel: NULL pointer dereference in x86_emulate_insn may lead to DoS (CVE-2022-1852)

* kernel: use after free flaw in l2cap_conn_del in net/bluetooth/l2cap_core.c (CVE-2022-3640)

* kernel: Information leak in l2cap_parse_conf_req in net/bluetooth/l2cap_core.c (CVE-2022-42895)

* kernel: veth: ensure skb entering GRO are not cloned. (CVE-2021-47099)

Solution:

https://access.redhat.com/articles/11258

CVEs:

CVE-2021-26341

References:

https://access.redhat.com/security/updates/classification/#moderate  
https://bugzilla.redhat.com/show_bug.cgi?id=2061703  
https://bugzilla.redhat.com/show_bug.cgi?id=2070205  
https://bugzilla.redhat.com/show_bug.cgi?id=2089815  
https://bugzilla.redhat.com/show_bug.cgi?id=2139610  
https://bugzilla.redhat.com/show_bug.cgi?id=2147356  
https://bugzilla.redhat.com/show_bug.cgi?id=2267919

Red Hat Security Advisory 2024-1877-03

There are also two out-of-bounds write vulnerabilities in the AMD Radeon user mode driver for DirectX 11.

Wednesday, April 10, 2024 12:56

Cisco Talos’ Vulnerability Research team has disclosed 10 vulnerabilities over the past three weeks, including four in a line of TP-Link routers, one of which could allow an attacker to reset the devices’ settings back to the factory default. 

A popular open-source software for internet-of-things (IoT) and industrial control systems (ICS) networks also contains multiple vulnerabilities that could be used to arbitrarily create new files on the affected systems or overwrite existing ones. 

For Snort coverage that can detect the exploitation of these vulnerabilities, download the latest rule sets from Snort.org, and our latest Vulnerability Advisories are always posted on Talos Intelligence’s website.  

**Denial-of-service, remote code execution vulnerabilities in TP-Link AC1350 router **

Talos researchers recently discovered four vulnerabilities in the TP-Link AC1350 wireless router. The AC1350 is one of many routers TP-Link produces and is designed to be used on home networks. 

TALOS-2023-1861 (CVE-2023-49074) is a denial-of-service vulnerability in the TP-Link Device Debug Protocol (TDDP). An attacker could exploit this vulnerability by sending a series of unauthenticated packets to the router, potentially causing a denial of service and forcing the device to reset to its factory settings.  

However, the TDDP protocol is only denial of serviceavailable for roughly 15 minutes after a device reboot.  

The TDDP protocol is also vulnerable to TALOS-2023-1862 (CVE-2023-49134 and CVE-2023-49133), a command execution vulnerability that could allow an attacker to execute arbitrary code on the targeted device. 

There is another remote code execution vulnerability, TALOS-2023-1888 (CVE-2023-49912, CVE-2023-49909, CVE-2023-49907, CVE-2023-49908, CVE-2023-49910, CVE-2023-49906, CVE-2023-49913, CVE-2023-49911) that is triggered if an attacker sends an authenticated HTTP request to the targeted device. This exploit includes multiple CVEs because an attacker could overflow multiple buffers to cause this condition. 

TALOS-2023-1864 (CVE-2023-48724) also exists in the device’s web interface functionality. An adversary could exploit this vulnerability by sending an unauthenticated HTTP request to the targeted device, thus causing a denial of service. 

**Multiple vulnerabilities in OAS Platform **

_Discovered by Jared Rittle._ 

Open Automation Software’s OAS Platform is an IoT gateway and protocol bus. It allows administrators to connect PLCs, devices, databases and custom apps. 

There are two vulnerabilities — TALOS-2024-1950 (CVE-2024-21870) and TALOS-2024-1951 (CVE-2024-22178) — that exist in the platform that can lead to arbitrary file creation or overwrite. An attacker can send a sequence of requests to trigger these vulnerabilities.  

An adversary could also send a series of requests to exploit TALOS-2024-1948 (CVE-2024-24976), but in this case, the vulnerability leads to a denial of service. 

An improper input validation vulnerability (TALOS-2024-1949/CVE-2024-27201) also exists in the OAS Engine User Configuration functionality that could lead to unexpected data in the configuration, including possible decoy usernames that contain characters not usually allowed by the software’s configuration. 

**Arbitrary write vulnerabilities in AMD graphics driver **

_Discovered by Piotr Bania._ 

There are two out-of-bounds write vulnerabilities in the AMD Radeon user mode driver for DirectX 11. TALOS-2023-1847 and TALOS-2023-1848 could allow an attacker with access to a malformed shader to potentially achieve arbitrary code execution after causing an out-of-bounds write. 

AMD graphics drivers are software that allows graphics processing units (GPUs) to communicate with the operating system.  

These vulnerabilities could be triggered from guest machines running virtualization environments to perform guest-to-host escape. Theoretically, an adversary could also exploit these issues from a web browser. Talos has demonstrated with past, similar, vulnerabilities that they could be triggered from HYPER-V guest using the RemoteFX feature, leading to executing the vulnerable code on the HYPER-V host.

Vulnerability in some TP-Link routers could lead to factory reset

In confidential computing environments, attestation is crucial in verifying the trustworthiness of the location where you plan to run your workload or where you plan to send confidential information. Before actually running the workload or transmitting the confidential information, you need to perform attestation.This blog provides an overview of the components implemented in the confidential containers (CoCo) to support the IETF RATS model (Remote ATtestation procedureS Architecture). The components include the Attestation Service (AS), Key Broker Service (KBS), Reference Value Provider Servi

In confidential computing environments, _attestation_ is crucial in verifying the trustworthiness of the location where you plan to run your workload or where you plan to send confidential information. Before actually running the workload or transmitting the confidential information, you need to perform **attestation**.

This blog provides an overview of the components implemented in the confidential containers (CoCo) to support the IETF RATS model **(Remote ATtestation procedureS Architecture)**. The components include the Attestation Service (AS), Key Broker Service (KBS), Reference Value Provider Service (RVPS), Attestation Agent (AA), and Confidential Data Hub (CDH). The AS, KBS, and RVPS components are part of the Trustee project, whereas the AA and CDH are part of the guest-components project in CoCo.

We begin by introducing the RATS model and its components. After that, we discuss the Trustee project, its various components, and how they relate to the RATS model. Finally, we present a few use cases that demonstrate the usage of the CoCo Trustee and guest-components project.

**RATS architecture and key components**

The key components in the RATS architecture are described in the following diagram:

*   **Attester** - provides **Evidence**, which is evaluated and appraised to decide its trustworthiness (for instance, a test to see whether it’s authorized to perform some action). Evidence may include configuration data, measurements, telemetry, or inferences.
*   **Verifier** - evaluates the validity of the evidence received from the attester and produces **attestation results**, which are sent to the Relying party. Attestation results typically include information regarding the Attester, while the Verifier vouches for the validity of the results.
*   **Relying party** - depends on the validity of information originating from the attester for reliably applying an action. This information can come from the verifier or directly through the attester.
*   **Relying party owner** - authorized to configure the appraisal policy that the **relying party** will use when receiving the attestation results (such as admin).
*   **Verifier owner** - authorized to configure the appraisal policy the **verifier** will use when receiving the evidence.
*   **Endorser** - for us, the hardware manufacturer who provides an **endorsement**, which the **verifier** uses to validate the evidence received from the attester. The endorsement is a secure statement the Endorser vouches for on the integrity of an Attester's various capabilities
*   **Reference Value Provider** - for us the hardware manufacturer who provides **reference values**, which the verifier uses to verify that claims were recorded by the attester. Reference values are, for example, golden measurements or nominal values.

In practice, the data flow between the verifier, attester, and relying party can be done through the **passport check model** and **background check model**.

**Passport check model**

In the passport model, the **attester** validates an identification token with the **verifier**. It then presents the **identification token** to the **relying party**. It's a similar process to when you present your passport at an airport to confirm your own identity when entering a country.

In this model, the attester requests the passport from the verifier by providing **evidence** and receives a passport in the form of **attestation results**. It can now interact directly with the relying party by presenting its passport (attestation result).

The following diagram shows this flow: 

**Background check model**

In the background check model, the **relying party** asks for verification each time the **attester** presents its evidence. This is similar to performing a full background check on an individual every time the individual enters a country.

The attester provides **evidence** to the relying party, which forwards it directly to the verifier. The verifier compares the evidence with the **appraised policy** it contains, and returns an **attestation result** to the relying party. The relying party compares the attestation results with its own **appraisal policy**.

Unlike a passport model, where the attester sends **attestation results** to the relying party, the background model requires the attester to send the relying party **evidence** (which is sent as-is to the verifier).

The following diagram illustrates the background check model:

**The Trustee project**

The trustee project (previously known as CoCo KBS) includes components deployed on a trusted side and used to verify whether the remote workload is running in a trusted execution environment (TEE). It also verifies that the remote environment uses the expected software and hardware versions.

This diagram shows the architecture for the Trustee model:

The **left side** includes the **guest components** running inside the TEE, including the Attestation Agent (AA) and Confidential Data Hub (CDH). The **right side** includes the external components, which the guest components interact with, such as the Key Broker Service (KBS), Attestation Service (AS), and the Reference Value Provider Service (RVPS).

**Trustee and guest components****Key Broker Service (KBS)**

The Key Broker Service (KBS) facilitates remote attestation and managing and delivering secrets. Equating this to the RATS model, the KBS is the **relying party** entity. The KBS, however, doesn’t validate the attestation evidence. Instead, it uses the attestation service (AS) to verify the TEE evidence.

**Attestation Service (AS)**

The Attestation Service (AS) is responsible for validating the TEE evidence. This includes evidence from the following TEEs: Intel TDX, Intel SGX, AMD SEV-SNP, ARM CCA, Hygon CSV, and more.

When mapped to the RATS model, the AS is the equivalent of the **verifier**.

The AS receives attestation evidence and returns an attestation token containing the results of a two-step verification process. Note that the KBS is the client of the AS, however the evidence originates from the attestation agent (AA).

The following diagram shows the AS components:

The AS runs the following verification process:

1.  **Verify the formatting and the origin of the evidence** - for example, checking the signature of the evidence. This is accomplished by one of the platform-specific Verifier Drivers.
2.  **Evaluate the claims provided in the evidence** - for example, validating that the measurements are what the client expects. This is done by a Policy Engine with help from the RVPS.

**Verifier driver**

A verifier driver parses the attestation evidence provided by the hardware TEE. It performs the following tasks:

1.  Verifies the hardware TEE signature of the TEE quote and report provided in the evidence
2.  Receives the evidence and organizes the status into a JSON format to be returned

**Policy Engine**

The AS allows users to upload their own policies when performing evidence verification. When an attestation request is received by the AS, it uses a policy ID in the request to decide which policies should be evaluated. The results of all policies evaluated are included in the attestation response.

**Reference Value Provider Service (RVPS)**

The reference value provider service (RVPS) is a component in the AS responsible for verifying, storing, and providing reference values. RVPS receives and verifies inputs from the software supply chain, stores the measurement values, and generates reference value claims for the AS. This operation is performed based on the evidence verified by the AS.

The following diagram shows the RVPS components:

RVPS contains the preprocessors, extractors, and store components:

**Preprocessors**

These are plugins that preprocess the reference value registration messages before sending it to extractors.

**Extractors**

These are plugins that process different types of provenance in the input message. Each plugin consumes the input message, and then generates an output **Reference** value.

**Store**

The store component provides persistent storage for the reference values.

**Attestation Agent (AA)**

The Attestation Agent (AA) is the entity running inside the TEE that connects to the KBS in order to perform attestation.  AA is responsible for sending the evidence (claims) from the TEE to prove the trustworthiness of the environment.

**Confidential Data Hub (CDH)**

The Confidential Data Hub (CDH) facilitates secure key retrieval for kata-agent and applications. It also provides additional services, such as secure mount for external storage or key management client services to retrieve keys directly from external Key Management Services. The secure mount service enables mounting of encrypted storage inside the TEE. We'll cover the secure mount service in a subsequent blog.

The following diagram shows the CDH components:

**Resources for learning about the attestation flow**

For an **overview of attestation**, read our Learn about Confidential Computing Attestation blog series.

For details on **attestation flow in confidential containers**, read our Understanding the Confidential Containers Attestation Flow article.

For a **step-by-step flow of confidential containers attestation on Azure** cloud, read our Confidential Containers on Azure with OpenShift: A technical deep dive article.

**Mapping Trustee components to the RATS model**

This is how the RATS model maps to the Trustee components model:

Note the following:

*   The **Attester** functionally is performed by the **AA** and **CDH** guest side components.
*   The **Verifier** is mapped to the **AS**.
*   The **Relying party** is mapped to the **KBS** receiving attestation results from the AS, and performing actions based on the results.
*   The **Endorser** usually originates from the platform manufacturer (Intel, AMD, IBM, and so on), so it can be the manufacturer itself or a CSP that got endorsed by the hardware manufacturer.
*   The **Reference Value Provider** is mapped to the **RVPS** and provides the endorsed reference. Note that reference values do not originate from the hardware manufacturer, but rather they reference measurements of the kernel, firmware image, and so on. They are trusted artifacts meaning signed by an identity you can trust and are used for performing the verification.
*   The **Verify owner** and **Relying Party** owner are the entities who operate the KBS and AS on the user's behalf.

**Background check model**

The background check model is a common way to configure the KBS and AS components, so we present it before the passport model. The following diagram shows the model: 

In this model, the AA communicates with the KBS providing the hardware evidence and the KBS communicates with the AS to verify it. After the evidence is verified, the KBS releases the secrets back to the CDH when requested.

In background check mode, the KBS is the relying party, the AS is the verifier, and the AA is the attester.

**Passport model**

In the passport model, the validation of evidence and provisioning of resources are typically handled by  different KBSes. The following diagram shows the model: 

We now have 2 KBS entities:

*   The first KBS, with the AS, verifies the evidence from the guest.
*   The second KBS provides secrets to the guest.

The AA interacts with **upper KBS + AS (Trustee 1)** in order to attest, verify the evidence, and receive a token (a passport). It then requests the secret resources from the **lower KBS (Trustee 2)**.

In practice, we recommend using the passport model when the attestation and resource provisioning are handled by separate entities.

**Attestation use cases leveraging Trustee components**

There are many use cases that can leverage the Trustee and guest components. For simplicity, we focus on the **background check model** (a single KBS) and not the **passport model** (with two KBS entities).

**Attestation for virtual machines (VMs) and their workloads**

Confidential VMs (CVMs) leverage hardware-based security features, such as AMD SEV-SNP (Secure Encrypted Virtualization-Secure Nested Paging) or Intel TDX (Trust Domain Extensions) to provide a secure execution environment for sensitive workloads. These VMs confirm that code and data remain encrypted and isolated, even from other privileged softwares on the host system. However, validating the integrity of these VMs and their underlying hardware is critical to guaranteeing the confidentiality and security of the data that is processed.

For a detailed description of confidential VMs, read our Learn about Red Hat Confidential Virtual Machines blog series.

VM attestation verifies the integrity of a confidential VM and its underlying platform components, including the CPU, firmware, and hypervisor. The attestation process might be initiated by the firmware or initrd.

From a trust perspective, you need assurance that the VM you just created on a public cloud is really a CVM with an operating system of your choice. In particular, you need to make sure that the host hasn’t started a non-confidential VM with a specially crafted guest operating system to steal your secrets instead.

The following diagram shows the overall architecture for VM attestation: 

Note the following:

*   The CVM can run over a KVM hypervisor, some other hypervisor on bare metal or on a public cloud provider infrastructure.
*   The AA works with the Trustee AS.

Here is a list of Trustee and guest components being used:

**Trustee components**

**Guest components**

KBS

AA

AS

 

RVPS

 

**Attestation for a confidential containers workload**

Moving from the VM level attestation to a container level attestation, let’s focus on container workload the user wants to run in a secure manner protected from the host.

Attestation for confidential containers verifies the container runtime stack running in the confidential environment. This includes kata-agent, supporting services like agent-protocol-forwarder, process-user-data, open policy agent, and default policies that are needed to run the container.

If the confidential containers are using the VM trusted execution environment, then the attestation includes attestation of the VM followed by attestation of the container runtime components. This diagram shows the overall architecture for confidential container attestation: 

Note the following:

*   Peer-pods are used for running confidential containers over VMs (on-prem and public cloud). For additional details, read Deploying confidential containers on the public cloud
*   The trustee model is used twice in this case to attest the CVM and then attest the confidential container runtime components

Here's a list of Trustee and guest components being used:

**Trustee components**

**Guest components**

KBS

AA

AS

 

RVPS

 

**Attestation to retrieve container image signing or decryption keys**

This use case is specific to obtaining the key for signature verification of a signed container image or obtaining the decryption key for encrypted images. For example, you might use encrypted container images to ship proprietary or sensitive code, such as AI models.

If the confidential containers are using the VM trusted execution environment, then the attestation process begins with VM attestation to confirm the integrity of the underlying execution environment. Once the VM's trustworthiness is established, container attestation proceeds, confirming the authenticity and integrity of the container runtime components. After a successful attestation, the container runtime requests the key from the Key Broker Service (KBS) for signature verification or decryption of the container images before starting the application.

The following diagram shows the overall architecture for retrieving the container image signing or decryption keys:

The attestation process is similar to attesting a confidential container workload, with the extra step of CDH retrieving the signing or decryption key that gets used by the kata-agent for signature verification or decrypting the container image.

This is a list of Trustee and guest components being used:

**Trustee components**

**Guest components**

KBS

AA

AS

CDH

RVPS

 

**Attestation for releasing application secrets**

This use case is specific to obtaining the key used by the workload. An example use case for obtaining the key is **Data Clean Rooms**. 

A number of organizations want to analyze data without compromising the privacy of individuals whose data is being analyzed (a joint bank fraud detection effort, for example). They're required to create a shared secured environment for data leaving the boundaries of those individuals. They would also want that environment to run in the cloud at scale. This can be accomplished by a secure key release where the data decryption key is only released to a specific TEE based on attestation.

The following diagram shows the idea: 

If the confidential containers are using the VM trusted execution environment, then the attestation process begins with VM attestation to ensure the integrity of the underlying execution environment. Once the VM's **trustworthiness** is established, container attestation proceeds, confirming the authenticity and integrity of the container runtime components. After a successful attestation, the container runtime starts the application.

The application then starts another attestation sequence to request the application secret from the Key Broker Service (KBS).  Confidential Data Hub (CDH) is used to request the application secret from the KBS by initiating an attestation sequence to prove the trustworthiness of the environment.

The following diagram shows the additional step of obtaining the application secret:

Note the following:

*   The attestation process is similar to attesting a confidential container workload, with the extra step of CDH retrieving the application secrets and providing it to the application
*   If the container images are signed or encrypted, then first the signing or decryption key is fetched (as described in the previous use case), followed by the application secret retrieval by CDH

Here's a list of Trustee and guest components being used:

**Trustee components**

**Guest components**

KBS

AA

AS

CDH

RVPS

 

**Trustee project and confidential computing**

In this blog we have introduced the Trustee project which is part of the confidential containers CNCF initiative and includes a number of services providing attestation capabilities for containers, VMs, shared keys and more.

We’ve covered the IETF RATS model, reviewed the Trustee components and showed the mapping between Trustee and the RATS model. We’ve also reviewed a number of use cases requiring attestation and presented how the Trustee components are used for those purposes.

In future blogs, we'll dive deeper into the Trustee projects looking at the technical details and hands on instructions on how to try out things.

Introducing Confidential Containers Trustee: Attestation Services Solution Overview and Use Cases

Red Hat Security Advisory 2024-1614-03 - An update for kernel-rt is now available for Red Hat Enterprise Linux 8. Issues addressed include code execution, null pointer, privilege escalation, and use-after-free vulnerabilities.

The following advisory data is extracted from:

https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_1614.json

Red Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.

- Packet Storm Staff

====================================================================  
Red Hat Security Advisory

Synopsis:           Important: kernel-rt security and bug fix update  
Advisory ID:        RHSA-2024:1614-03  
Product:            Red Hat Enterprise Linux  
Advisory URL:       https://access.redhat.com/errata/RHSA-2024:1614  
Issue date:         2024-04-03  
Revision:           03  
CVE Names:          CVE-2021-33631  
====================================================================

Summary: 

An update for kernel-rt is now available for Red Hat Enterprise Linux 8.

Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.

Description:

The kernel-rt packages provide the Real Time Linux Kernel, which enables fine-tuning for systems with extremely high determinism requirements.

Security Fix(es):

* kernel: vmwgfx: NULL pointer dereference in vmw_cmd_dx_define_query (CVE-2022-38096)

* kernel: Out of boundary write in perf_read_group() as result of overflow a perf_event's read_size (CVE-2023-6931)

* kernel: GSM multiplexing race condition leads to privilege escalation (CVE-2023-6546,ZDI-CAN-20527)

* kernel: CIFS Filesystem Decryption Improper Input Validation Remote Code Execution Vulnerability in function receive_encrypted_standard of client (CVE-2024-0565)

* kernel: use-after-free in amdgpu_cs_wait_all_fences in drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c (CVE-2023-51042)

* kernel: ext4: kernel bug in ext4_write_inline_data_end() (CVE-2021-33631)

* kernel: nf_tables: use-after-free vulnerability in the nft_verdict_init() function (CVE-2024-1086)

Bug Fix(es):

* kernel-rt: update RT source tree to the latest RHEL-8.9.z3 Batch (JIRA:RHEL-23853)

* kernel-rt: kernel: nf_tables: use-after-free vulnerability in the nft_verdict_init() function (JIRA:RHEL-24015)

* kernel-rt: kernel: vmxgfx: NULL pointer dereference in vmw_cmd_dx_define_query (JIRA:RHEL-22758)

* kernel-rt: kernel: CIFS Filesystem Decryption Improper Input Validation Remote Code Execution Vulnerability in function receive_encrypted_standard of client (JIRA:RHEL-22080)

* kernel-rt: kernel: Out of boundary write in perf_read_group() as result of overflow a perf_event's read_size (JIRA:RHEL-22933)

* kernel-rt: kernel: use-after-free in amdgpu_cs_wait_all_fences in drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c (JIRA:RHEL-24498)

* kernel-rt: kernel: GSM multiplexing race condition leads to privilege escalation (JIRA:RHEL-19966)

* kernel-rt: kernel: ext4: kernel bug in ext4_write_inline_data_end() (JIRA:RHEL-26334)

Solution:

https://access.redhat.com/articles/11258

CVEs:

CVE-2021-33631

References:

https://access.redhat.com/security/updates/classification/#important  
https://bugzilla.redhat.com/show_bug.cgi?id=2133452  
https://bugzilla.redhat.com/show_bug.cgi?id=2252731  
https://bugzilla.redhat.com/show_bug.cgi?id=2255498  
https://bugzilla.redhat.com/show_bug.cgi?id=2258518  
https://bugzilla.redhat.com/show_bug.cgi?id=2259866  
https://bugzilla.redhat.com/show_bug.cgi?id=2261976  
https://bugzilla.redhat.com/show_bug.cgi?id=2262126

Red Hat Security Advisory 2024-1614-03

Fortanix is working on technologies to build a security wall around AI search.

The inner functioning of AI-powered search is more complex than plain-text search via Google when it comes to extracting answers from websites and databases. Fortanix is trying to build a security wall to protect the search query and the extraction of data from artificial intelligence (AI) systems.

Generative AI technologies will ultimately provide fine-grained responses based on associativity of information and retrieve information from sources users may not be aware of, says Richard Searle, vice president of confidential computing at Fortanix.

"What we're finding ... is that there is a deeper focus happening in the AI domain around privacy, consent, and permissioning of information," Searle says. "These are obviously the core cases."

Essentially, Fortanix is building a security wall around the way AI search queries are handled. More specifically, it is building security around prompts, where users provide AI search queries. The security wall extends to data retrieval from large language models, which are delivered to customers.

"We think there's a significant market there," Searle says. "The partners that we're working with within the AI space are talking about search to their customers already today."

Fortanix's private AI search is pinned on confidential computing, which creates secure vaults that are accessible to authorized parties only via keys. The data is processed inside, without leaving the vault.

"Data is going to be subject to not only the data protection regulations that we have today, but also these emerging AI regulations," Searle says.

Fortanix's technology is a component in the emerging field of confidential AI. Confidential AI is extended to AI scenarios typically associated with GPUs and accelerators, said Mark Russinovich, chief technology officer for Microsoft Azure, during a panel discussion at the Open Confidential Computing Conference in March.

**Protecting Vector Databases**

Private search with AI relies on data extraction from knowledge graphs or vector databases, which could draw information from a wide range of sources, including static conventional databases.

At Nvidia's GPU Technology Conference, also in March, the company's CEO, Jensen Huang, defined vector databases as a new style of database that takes structured data or unstructured data that can be reindexed by encoding the meaning of data.

"Now this becomes an AI database, and that AI database in the future, once you create it, you can talk to it," Huang said.

Fortanix's goal is to initiate privacy for the search initiator — a human or machine user — and protect the privacy and integrity of the information that might be within the vector embeddings.

"Confidential computing, I think, has a very important role to play," Fortanix’s Searle says.

**Private Search Differs From Conventional Search**

Confidential AI prevents the leak of AI information, which helps meet regulatory requirements. The layer also anonymizes the information so a user's intent or identity is protected. That is the opposite of conventional search, where user information and motives drive Google Ads and analytics.

A higher level of AI privacy is a cornerstone for industries such as healthcare and banking, which are tied to regulatory issues.

"Imagine that you want to do search in a scientific domain — you might want to be able to use data from a different institution to the one you're working in that has some specific expertise in a particular field. Showing the privacy of that data and the accuracy of this research is important," Searle says.

**State of Confidential AI**

Confidential AI is an emerging concept, and search fits into that profile. Intel and AMD have chips with hooks for secure enclaves. Microsoft, Google, and Amazon are providing confidential computing virtual machines in their cloud services.

Companies can bring data sets together to train a foundational model effectively, and these data sets are becoming high-value assets for top corporations, said Ian Buck, vice president and general manager of Nvidia's hyperscale and high-performance computing division, during the panel discussion.

The IT industry is rapidly approaching the deployment of confidential computing in data centers, edge computing, and PCs, but there's a lot more to do with confidential AI, said Greg Lavender, Intel's chief technology officer, during the panel.

"Privacy and safety and responsible AI are going to be big forcing functions for this as the government adopts AI technologies from the industry," he said.

**About the Author(s)**

Agam Shah has covered enterprise IT for more than a decade. Outside of machine learning, hardware, and chips, he's also interested in martial arts and Russia.

Fortanix Builds Private Search for AI

Red Hat Security Advisory 2024-1607-03 - An update for kernel is now available for Red Hat Enterprise Linux 8. Issues addressed include code execution, null pointer, privilege escalation, and use-after-free vulnerabilities.

The following advisory data is extracted from:

https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_1607.json

Red Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.

- Packet Storm Staff

====================================================================  
Red Hat Security Advisory

Synopsis:           Important: kernel security, bug fix, and enhancement update  
Advisory ID:        RHSA-2024:1607-03  
Product:            Red Hat Enterprise Linux  
Advisory URL:       https://access.redhat.com/errata/RHSA-2024:1607  
Issue date:         2024-04-02  
Revision:           03  
CVE Names:          CVE-2021-33631  
====================================================================

Summary: 

An update for kernel is now available for Red Hat Enterprise Linux 8.

Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.

Description:

The kernel packages contain the Linux kernel, the core of any Linux operating system.

Security Fix(es):

* kernel: vmwgfx: NULL pointer dereference in vmw_cmd_dx_define_query (CVE-2022-38096)

* kernel: Out of boundary write in perf_read_group() as result of overflow a perf_event's read_size (CVE-2023-6931)

* kernel: GSM multiplexing race condition leads to privilege escalation (CVE-2023-6546,ZDI-CAN-20527)

* kernel: CIFS Filesystem Decryption Improper Input Validation Remote Code Execution Vulnerability in function receive_encrypted_standard of client (CVE-2024-0565)

* kernel: use-after-free in amdgpu_cs_wait_all_fences in drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c (CVE-2023-51042)

* kernel: ext4: kernel bug in ext4_write_inline_data_end() (CVE-2021-33631)

* kernel: nf_tables: use-after-free vulnerability in the nft_verdict_init() function (CVE-2024-1086)

Bug Fix(es):

* OCP 4.12 crashed due to use-after-free in libceph in rhel8 (JIRA:RHEL-21394)

* kernel: nf_tables: use-after-free vulnerability in the nft_verdict_init() function (JIRA:RHEL-24010)

* Screen floods with random colour suggesting something not initialised (JIRA:RHEL-21055)

* kernel: vmxgfx: NULL pointer dereference in vmw_cmd_dx_define_query (JIRA:RHEL-22766)

* tx-checksumming required for accessing port in OpenShift for RHEL 8.6 (JIRA:RHEL-20822)

* kernel: CIFS Filesystem Decryption Improper Input Validation Remote Code Execution Vulnerability in function receive_encrypted_standard of client (JIRA:RHEL-22077)

* kernel: Out of boundary write in perf_read_group() as result of overflow a perf_event's read_size (JIRA:RHEL-22930)

* rbd: don't move requests to the running list on errors [8.x] (JIRA:RHEL-24204)

* kernel: use-after-free in amdgpu_cs_wait_all_fences in drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c (JIRA:RHEL-24479)

* ceph: several cap and snap fixes (JIRA:RHEL-20909)

* [RHVH] Migration hangs between RHVH release bellow 4.5.1 and RHVH over or equal 4.5.2 release (JIRA:RHEL-23063)

* unable to access smsc95xx based interface unless you start outgoing traffic.  (JIRA:RHEL-25719)

* [RHEL8] ] BUG bio-696 (Not tainted): Poison overwritten  (JIRA:RHEL-26101)

* kernel: GSM multiplexing race condition leads to privilege escalation (JIRA:RHEL-19954)

* backport smartpqi: fix disable_managed_interrupts (JIRA:RHEL-26139)

* kernel: ext4: kernel bug in ext4_write_inline_data_end() (JIRA:RHEL-26331)

* ceph: always check dir caps asynchronously (JIRA:RHEL-27496)

Enhancement(s):

* [IBM 8.10 FEAT] Upgrade the qeth driver to latest from upstream, e.g. kernel 6.4 (JIRA:RHEL-25811)

Solution:

https://access.redhat.com/articles/11258

CVEs:

CVE-2021-33631

References:

https://access.redhat.com/security/updates/classification/#important  
https://bugzilla.redhat.com/show_bug.cgi?id=2133452  
https://bugzilla.redhat.com/show_bug.cgi?id=2252731  
https://bugzilla.redhat.com/show_bug.cgi?id=2255498  
https://bugzilla.redhat.com/show_bug.cgi?id=2258518  
https://bugzilla.redhat.com/show_bug.cgi?id=2259866  
https://bugzilla.redhat.com/show_bug.cgi?id=2261976  
https://bugzilla.redhat.com/show_bug.cgi?id=2262126

Red Hat Security Advisory 2024-1607-03

Cybersecurity researchers from ETH Zurich have developed a new variant of the RowHammer DRAM (dynamic random-access memory) attack that, for the first time, successfully works against AMD Zen 2 and Zen 3 systems despite mitigations such as Target Row Refresh (TRR).
"This result proves that AMD systems are equally vulnerable to Rowhammer as Intel systems, which greatly increases the attack

Tag

#amd