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

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

Hace poco se dio a conocer la noticia por parte de los desarrolladores del proyecto GrapheneOS, sobre una vulnerabilidad que detectaron en Android 14 en la pila Bluetooth LE, el error se debe a una corrupción de memoria introducido en Android 14 QPR2.

Para quienes desconocen de GrapheneOS, deben saber que este es un proyecto que desarrollar una versión segura del código base de AOSP, y ellos fueron quienes detectaron la vulnerabilidad en la pila Bluetooth de Android 14 la cual mencionan que puede ser explotada y permite conducir a la ejecución remota de código.

Sobre la vulnerabilidad, los desarrolladores de GrapheneOS mencionan que esta se origina en el acceso a un área de memoria liberada previamente, lo que se conoce como «uso después de liberación» (use-after-free). El problema se encuentra en el código encargado de procesar audio transmitido a través de Bluetooth LE.

Nuestra compatibilidad con el etiquetado de memoria de hardware para Pixel 8 y Pixel 8 Pro ha descubierto un error de corrupción de memoria introducido en Android 14 QPR2 para Bluetooth LE. Actualmente lo estamos investigando para determinar cómo solucionar o desactivar temporalmente la función recién introducida como solución alternativa.

La identificación de esta vulnerabilidad se debe en parte a la implementación de protecciones adicionales mediante la función hardened_malloc, que utiliza la extensión ARMv8.5 MTE. Esta extensión permite asignar etiquetas a cada operación de asignación de memoria y realizar verificaciones para garantizar el uso correcto de los punteros, evitando así la explotación de vulnerabilidades relacionadas con el acceso a memoria liberada, desbordamientos de búfer, llamadas a funciones antes de su inicialización y uso fuera del contexto actual.

Este error comenzó a surgir después de la actualización a Android 14 QPR2 (versión trimestral de plataforma), lanzada a principios de marzo. En la versión principal del código de Android 14, la funcionalidad MTE está disponible como opción pero aún no se encuentra habilitada de forma predeterminada.

Sin embargo, en GrapheneOS, se ha activado la protección MTE para proporcionar una capa adicional de seguridad, lo que permitió identificar el error después de la actualización a Android 14 QPR2. Este error causó bloqueos al utilizar auriculares Bluetooth Samsung Galaxy Buds2 Pro con firmware que habilitaba la protección basada en MTE. El análisis posterior del incidente reveló que el problema estaba relacionado con el acceso a memoria liberada en el controlador Bluetooth LE, y no fue causado por la integración de la funcionalidad MTE en sí misma.

Por la parte de las posibles soluciones a la vulnerabilidad, los desarrolladores de GrapheneOS mencionan que el deshabilitar el etiquetado de memoria para este proceso no es una solución alternativa aceptable ni siquiera a corto plazo porque es una superficie de ataque importante, independientemente de que este error en particular resulte explotable o no. Esto solo ocurre con ciertos dispositivos Bluetooth LE, no con todos los dispositivos Bluetooth.

La vulnerabilidad mencionada se ha solucionado en la versión 2024030900 de GrapheneOS. Es importante destacar que esta vulnerabilidad afecta a versiones de teléfonos inteligentes que no cuentan con protección de hardware adicional basada en la extensión MTE. Actualmente, la extensión MTE está habilitada únicamente para dispositivos Pixel 8 y Pixel 8 Pro.

Desarrollamos un parche para el error de uso después de la liberación de QPR2 de Android 14 que descubrimos con Bluetooth LE. Nuestra prioridad es lanzar pronto una versión de GrapheneOS con nuestra solución y lo informaremos como un error de seguridad de Android. Esto también debería resolver las regresiones de audio BLE.

La vulnerabilidad se ha observado en los smartphones Google Pixel 8 con firmware basado en Android 14 QPR2. Para los dispositivos de la serie Pixel 8, es posible habilitar el modo MTE en la configuración del desarrollador. Esto se puede hacer accediendo a «Configuración/Sistema/Opciones de desarrollador/Extensiones de etiquetado de memoria». Es importante tener en cuenta que habilitar MTE conlleva un aumento en el consumo de memoria de aproximadamente un 3 %, pero no afecta el rendimiento del dispositivo.

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/cB4Igub
via IFTTT