#amd

Dell BIOS contains an Improper Input Validation vulnerability. An unauthenticated physical attacker may potentially exploit this vulnerability to perform arbitrary code execution.

pam_krb5 authenticates a user by essentially running kinit with the password, getting a ticket-granting ticket (tgt) from the Kerberos KDC (Key Distribution Center) over the network, as a way to verify the password. However, if a keytab is not provisioned on the system, pam_krb5 has no way to validate the response from the KDC, and essentially trusts the tgt provided over the network as being valid. In a non-default FreeBSD installation that leverages pam_krb5 for authentication and does not have a keytab provisioned, an attacker that is able to control both the password and the KDC responses can return a valid tgt, allowing authentication to occur for any user on the system.

This article is the last in a six-part series (see my previous blog) presenting various usage models for Confidential Computing, a set of technologies designed to protect data in use. In this article, I explore interesting support technologies under active development in the confidential computing community. Kernel, hypervisor and firmware support Confidential Computing requires support from the host and guest kernel, the hypervisor, and firmware. At the time of writing, that support is uneven between platforms. Hardware vendors tend to develop and submit relatively large patch series, w

The Red Hat Enterprise Linux 9.2 CVM Preview image for Azure confidential VMs has been released, and it represents an important step forward in confidential virtual machines. In this article, I focus on the changes Implemented to support the emerging confidential computing use-case, and some of the expected changes in the future. For this article, I'm using confidential virtual machines (CVMs) with the Technology Preview of Red Hat Enterprise Linux 9.2, running as a guest on Microsoft Azure confidential VMs. This builds on my previous post in which I discussed the high-level requirements fo

Confidential Computing is a set of technologies designed to protect data in use (for example, it provides memory encryption). This article is fifth in a six-part series (see the previous article), about various Confidential Computing usage models, and the requirements to get the expected security and trust benefits. In this article, I explore the many available Confidential Computing platforms, and discuss how they differ in implementation, and specifically in how to perform attestation: AMD Secure Encrypted Virtualization (SEV) in its three generations (SEV, SEV-ES and SEV-SNP) Intel

RenderDoc versions 1.26 and below suffer from integer underflow, integer overflow, and symlink vulnerabilities.

In this post, we will present confidential virtual machines (CVMs) as one of the use cases of confidential computing as well as the security benefits expected from this emerging technology. We will focus on the high level requirements for the Linux guest operating system to ensure data confidentiality both in use and at rest. This blog follows the recent release of Red Hat Enterprise Linux 9.2 running on Azure Confidential VMs. CVMs are also a critical building block for the upcoming OpenShift confidential containers in OpenShift 4.13 (dev-preview). For additional details on OpenShift

Confidential containers (CoCo) is a new feature of Red Hat OpenShift sandboxed containers that leverages Trusted Execution Environment (TEE) technology to isolate your containers from the host and other containers. In this blog post, you will learn how to set up OpenShift sandboxed containers with confidential containers support on an OpenShift cluster hosted on Azure, using AMD SEV-SNP technology. You will also see how to create and run a confidential container that can process confidential data more securely and efficiently. For more information on confidential containers running on Az

RenderDoc through 1.26 allows an Integer Overflow with a resultant Buffer Overflow (issue 1 of 2).

Ubuntu Security Notice 6134-1 - It was discovered that the Traffic-Control Index implementation in the Linux kernel did not properly perform filter deactivation in some situations. A local attacker could possibly use this to gain elevated privileges. Please note that with the fix for this CVE, kernel support for the TCINDEX classifier has been removed. It was discovered that the Traffic-Control Index implementation in the Linux kernel contained a use-after-free vulnerability. A local attacker could use this to cause a denial of service or possibly execute arbitrary code.