RFDS, una vulnerabilidad que afecta a procesadores Intel E-core

vulnerabilidad

Si se explotan, estas fallas pueden permitir a los atacantes obtener acceso no autorizado a información confidencial o, en general, causar problemas

Intel dio a conocer hace poco, la noticia de que detecto una vulnerabilidad de microarquitectura (catalogada bajo CVE-2023-28746) en los procesadores Intel Atom (E-core), conocida como RFDS (Register File Data Sampling) y el peligro de esta vulnerabilidad radica en que permite determinar los datos utilizados por un proceso que se ejecutaba previamente en el mismo núcleo de la CPU.

RFDS es una vulnerabilidad que comparte similitudes con ataques de muestreo de datos, como el muestreo de datos microarquitectónicos (MDS), se diferencia en su método de exposición y los datos expuestos, limitándose a datos de registros obsoletos.

Sobre la vulnerabilidad

La identificación de «RFDS» fue realizada por ingenieros de Intel durante una auditoría interna, aunque no se ha proporcionado información detallada sobre el método de explotación de la misma, los ingenieros de Intel han señalado que el atacante no puede controlar intencionalmente la selección de procesos para la extracción de datos, lo que implica que la exposición de información disponible para su recuperación es aleatoria. Sin embargo, la explotación de RFDS por parte de un actor malicioso que pueda ejecutar código localmente en un sistema podría conducir a la inferencia de valores de datos secretos previamente utilizados en registros, potencialmente comprometiendo la seguridad y confidencialidad de la información.

RFDS se descubrió como parte del extenso trabajo de validación interna de Intel sobre seguridad de microarquitectura. De manera similar a los ataques de ejecución transitoria de muestreo de datos, como el muestreo de datos microarquitectónicos (MDS), RFDS puede permitir que un actor malicioso que puede ejecutar código localmente en un sistema infiera los valores de datos secretos que de otro modo estarían protegidos por mecanismos arquitectónicos. RFDS difiere de las vulnerabilidades de MDS tanto en el método de exposición como en los datos expuestos (RFDS expone únicamente datos de registros obsoletos). Ni MDS ni RFDS, por sí solos, brindan a los actores maliciosos la capacidad de elegir qué datos se infieren utilizando estos métodos.

Se menciona que estas fugas afectan a los registros vectoriales utilizados en cifrado, funciones de copia de memoria y procesamiento de cadenas, como en las funciones memcpy, strcmp y strlen. También es posible la fuga a través de registros para almacenar números de punto flotante y enteros, aunque se actualizan con más frecuencia durante la ejecución de tareas, lo que reduce la probabilidad de fugas a través de ellos. Es importante destacar que los datos residuales no permanecen directamente en los registros, sino que se pueden extraer de los archivos de registro mediante técnicas de ataque de canal lateral, como la extracción de datos en la memoria caché de la CPU.

RFDS afecta exclusivamente a los procesadores Atom basados en las microarquitecturas Alder Lake, Raptor Lake, Tremont, Goldmont y Gracemont. Estos procesadores no admiten el modo HyperThreading, lo que limita la fuga de datos a un subproceso de ejecución dentro del núcleo de la CPU actual. Los cambios para abordar esta vulnerabilidad están incluidos en la actualización del microcódigo microcode-20240312-staging.

Los métodos de protección contra esta vulnerabilidad son similares a los utilizados para bloquear ataques previamente identificados, como MDS, SRBDS, TAA, DRPW (Device Register Partial Write), y ataques SBDS (Shared Buffer Data Sampling).

Para protegerse contra las fugas en el kernel y los hipervisores, además de actualizar el microcódigo, es necesario utilizar métodos de protección de software que involucran el uso de la instrucción VERW para borrar el contenido de los buffers de microarquitectura al regresar del kernel al espacio de usuario o al transferir el control al sistema de invitados. Esta protección ya ha sido implementada en el hipervisor Xen y el kernel de Linux.

Para habilitar la protección en el kernel de Linux, se puede utilizar el indicador «reg_file_data_sampling=on» al cargar el kernel. La información sobre la vulnerabilidad y la presencia del microcódigo necesario para la protección se puede evaluar en el archivo «/sys/devices/system/cpu/vulnerabilities/reg_file_data_sampling«.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

from Linux Adictos https://ift.tt/fuxA0Um
via IFTTT

Kernel-lts, el proyecto de OpenELA para dar soporte adicional a Kernerls LTS sin soporte 

Linux Kernel

Linux es un núcleo mayormente libre semejante al núcleo de Unix.​ Es uno de los principales ejemplos de software libre y de código abierto.

La OpenELA (Open Enterprise Linux Association), una asociación formada el año pasado por CIQ (Rocky Linux), Oracle y SUSE (de la que ya hablamos aquí en el blog en su momento) se ha unido para garantizar la compatibilidad con RHEL (Red Hat Enterprise Linux). Dentro de este marco, han presentado el proyecto kernel-lts, el cual proporcionará soporte adicional para algunas ramas obsoletas de kernels LTS después de que dejen de recibir soporte oficial.

Con el lanzamiento de este proyecto, la versión 4.14, será la primera rama del kernel que recibirá este soporte adicional (esta versión del Kernel fue lanzada en noviembre de 2017 y ha recibido soporte durante 6 años). En enero, el equipo de desarrollo del kernel dejó de mantener esta rama y OpenELA ha asumido el mantenimiento y las actualizaciones para el kernel 4.14 se lanzarán al menos hasta diciembre de 2024. Tras la última versión del kernel de Linux 4.14.336, el equipo de OpenELA ha lanzado las actualizaciones extendidas 4.14.337-openela, 4.14.338-openela y 4.14.339-openela.

El mantenimiento proporcionado por OpenELA seguirá las mismas reglas y procesos que se aplican a los kernels LTS estables normales. No habrá restricciones adicionales, como la vinculación a equipos o productos específicos. Las actualizaciones se publicarán basadas en el trabajo de seguimiento de correcciones en las ramas actuales del kernel y su migración a las ramas LTS extendidas mantenidas por OpenELA.

El proyecto OpenELA kernel-lts es el primer foro para que los proveedores de distribución empresarial de Linux agrupen nuestros recursos y colaboren en esos kernels más antiguos después de que finalice el soporte upstream para esos kernels», dijo Greg Marsden, vicepresidente senior de Oracle Linux, Oracle. «Los proveedores de distribución empresarial de Linux que contribuyen al proyecto kernel-lts tienen kernels empresariales más recientes que recomendamos para la mayoría de las cargas de trabajo».

«Como proveedores de distribución empresarial, a menudo tenemos la tarea de mantener la viabilidad del software incluso después de que finalice el soporte de la comunidad», afirmó Gregory M. Kurtzer, director ejecutivo de CIQ. “Creemos que la colaboración abierta es la mejor manera de mantener la infraestructura empresarial fundamental. A través de OpenELA, los proveedores, los usuarios y la comunidad de código abierto en general pueden trabajar juntos para brindar la longevidad que las organizaciones profesionales de TI requieren para Linux empresarial”

Además de brindar soporte a las ramas del kernel LTS, OpenELA mantiene un repositorio con paquetes que pueden ser utilizados como base para crear distribuciones totalmente compatibles binariamente con Red Hat Enterprise Linux, manteniendo un comportamiento idéntico (a nivel de errores) a RHEL y adecuados para su uso como reemplazos de RHEL. Este repositorio es mantenido conjuntamente por los equipos de desarrollo de distribuciones como Rocky Linux, Oracle Linux y SUSE Liberty Linux, todas compatibles con RHEL. Incluye los paquetes necesarios para crear distribuciones compatibles con las ramas RHEL 8 y 9 (con planes para RHEL 7 en el futuro). Cabe destacar que este repositorio reemplazó al repositorio git.centos.org, que fue descontinuado por Red Hat.

Los desarrolladores del kernel de Linux continúan manteniendo varias ramas a largo plazo, cada una con su propio período de soporte:

  1. Rama 6.6: Soportada hasta diciembre de 2026. Esta rama es utilizada en Ubuntu 24.04.
  2. Rama 6.1: Soportada hasta diciembre de 2026, con soporte adicional dentro de SLTS. Esta rama es utilizada en Debian 12 y la rama principal de OpenWRT.
  3. Rama 5.15: Soportada hasta octubre de 2026. Esta rama es utilizada en Ubuntu 22.04, Oracle Unbreakable Enterprise Kernel 7 y OpenWRT 23.05.
  4. Rama 5.10: Soportada hasta diciembre de 2026, con soporte adicional dentro de SLTS. Esta rama es utilizada en Debian 11, Android 12 y OpenWRT 22.
  5. Rama 5.4: Soportada hasta diciembre de 2025. Esta rama es utilizada en Ubuntu 20.04 LTS y Oracle Unbreakable Enterprise Kernel 6.
  6. Rama 4.19: Soportada hasta diciembre de 2024, con soporte adicional dentro de SLTS. Esta rama es utilizada en Debian 10 y Android 10.

Además, la Fundación Linux proporciona ramas SLTS (Super Long Term Support) basadas en los Kernels 4.4, 4.19, 5.10 y 6.1. Estas ramas SLTS se mantienen por separado y reciben soporte durante períodos extendidos de 10 a 20 años. El proyecto Civil Infrastructure Platform (CIP) es responsable de mantener estas ramas SLTS, con la participación de empresas como Toshiba, Siemens, Renesas, Bosch, Hitachi, MOXA, mantenedores de las ramas LTS del núcleo principal, desarrolladores de Debian y el proyecto KernelCI. Estas ramas SLTS están diseñadas para su aplicación en sistemas técnicos de infraestructura civil y en sistemas industriales críticos.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

from Linux Adictos https://ift.tt/J8TjoF0
via IFTTT