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 un investigador de seguridad de Google dio a conocer, mediante una publicación de blog, el descubrimiento de una nueva vulnerabilidad (CVE-2023-23583) en los procesadores Intel, con nombre en código Reptar, que afecta a varias CPU de escritorio, móviles y de servidor de Intel, pero especialmente a los sistemas en la nube que ejecutan máquinas virtuales de diferentes usuarios.

La vulnerabilidad «Reptar» permite que el sistema se cuelgue o bloquee cuando se realizan determinadas operaciones en sistemas invitados sin privilegios. Teóricamente, la vulnerabilidad se puede utilizar para escalar privilegios del tercer anillo de protección al cero (CPL0) y escapar de entornos aislados, pero este escenario aún no se ha confirmado en la práctica debido a las dificultades de depuración a nivel de microarquitectura.

El equipo de ingeniería de seguridad de la información de Google informó la vulnerabilidad a Intel, quien la reveló hoy. Gracias a la cuidadosa colaboración entre Google, Intel y los socios de la industria, se implementaron mitigaciones y los empleados de Google y nuestros clientes están protegidos.

Según el investigador, la vulnerabilidad está presente en una gran cantidad de familias de procesadores Intel y se informa que el problema aparece a partir de la décima generación de los procesadores Intel Core y la tercera generación de los procesadores Xeon Scalable, así como en los procesadores Xeon E/D/W.

Sobre Reptar

Se menciona que la vulnerabilidad se debe al hecho de que la ejecución de una instrucción «REP MOVSB» codificada con un prefijo «REX» (un prefijo de un solo byte) redundante da como resultado un comportamiento indefinido. El prefijo REX puede proporcionar bits adicionales a la siguiente instrucción para usarlos como operandos, por lo que permite codificar los 16 registros de propósito general posibles y estos bits opcionales dan espacio para codificar registros de propósito más general en la siguiente instrucción.

En agosto, nuestro proceso de validación produjo una afirmación interesante. Encontró un caso en el que agregar prefijos REX redundantes a una operación «rep movs» optimizada de FSRM parecía causar resultados impredecibles.

Observamos un comportamiento muy extraño durante las pruebas. Por ejemplo, bifurcaciones a ubicaciones inesperadas, bifurcaciones incondicionales que se ignoran y el procesador ya no registra con precisión el puntero de instrucción xsaveo calllas instrucciones.

Curiosamente, al intentar comprender lo que estaba sucediendo, veíamos un depurador que informaba estados imposibles.

El problema se descubrió durante las pruebas de prefijos redundantes, que en teoría deberían ignorarse, pero que en la práctica provocaban efectos extraños, como ignorar ramas incondicionales y romper el guardado de punteros en las instrucciones xsave y call. Un análisis más detallado mostró que agregar un prefijo redundante a la instrucción «REP MOVSB» provoca corrupción en el contenido del búfer ROB (ReOrder Buffer) utilizado para ordenar instrucciones.

Una característica interesante de x86 es que la decodificación de instrucciones es generalmente bastante relajada. Si utiliza un prefijo que no tiene sentido o entra en conflicto con otros prefijos, no sucederá gran cosa, normalmente simplemente se ignorará.

Este hecho es a veces útil; los compiladores pueden usar prefijos redundantes para rellenar una sola instrucción hasta un límite de alineación deseable.

Se cree que el error se debe a un cálculo incorrecto del tamaño de la instrucción «MOVSB» con un prefijo excesivo, lo que conduce a una violación del direccionamiento de las instrucciones escritas en el búfer ROB después de MOVSB ​​y al desplazamiento del puntero de instrucción.

Esta desincronización puede limitarse a la interrupción de los cálculos intermedios con la posterior restauración del estado integral. Pero si bloquea varios núcleos o subprocesos SMT al mismo tiempo, puede causar suficiente daño al estado de la microarquitectura como para bloquearlo.

Una revisión interna de Intel también mostró el potencial de explotación de la vulnerabilidad para aumentar los privilegios bajo ciertas condiciones.

Finalmente, cabe mencionar que para probar la integridad de los sistemas, se ha publicado una utilidad que crea las condiciones para la manifestación de vulnerabilidades, además de que la vulnerabilidad en cuestión se solucionó en la actualización del microcódigo 20231114.

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/3d6oaeO
via IFTTT

La rama RHEL 9 se está desarrollando con un proceso de desarrollo más abierto y utiliza la base del paquete CentOS Stream 9 como base

Hace poco Red Hat dio a conocer la disponibilidad de la nueva versión de RHEL 9.3, la cual es la primera versión cuyos paquetes rpm no se publicaron en el repositorio público de CentOS y se proporcionan a los clientes de la empresa únicamente a través de una sección cerrada del sitio que prohíbe la redistribución de datos.

En este lanzamiento, que se presenta de RHEL 9.3 se destacan las mejoras implementadas en DNF, pues se añadieron nuevos complementos»dnf leaves» para mostrar todos los paquetes instalados que no son dependencias de otros paquetes; «show-leaves» para mostrar paquetes similares instalados recientemente o paquetes que ya no se utilizan como dependencias después de una transacción.

También podremos encontrar el comando «reboot» en DNF para reiniciar automáticamente una vez completada la actualización y en el cual los siguientes modos están disponibles, «never» predeterminado sin reiniciar, «when-changed» el cua´l reiniciar después de cualquier actualización  y «when-needed» el cual reinicia solo si lo requieren los cambios instalados (por ejemplo, después de instalar una actualización del kernel o systemd). Para apagar en lugar de reiniciar, se proporciona el parámetro «–poweroff».

Otro de los cambios que se destaca es en NetworkManager, en el cual se ha agregado soporte para la opción «no-aaaa» en resolv.conf, que deshabilita las consultas DNS para registros AAAA, asi como tambien que se agregó soporte para la opción «lacp_active» para controlar el procesamiento de tramas LACPDU y se implementó el reinicio de NetworkManager después de reiniciar el servicio dbus.

Ademas de ello, OpenSSH ha comenzado a dejar de utilizar algoritmos basados ​​en hash SHA-1 en favor de SHA-2. Si el servidor no tiene claves basadas en SHA-1, sshd ahora solo usará SHA-2 para validar las claves del host, lo que puede resultar en incompatibilidad con clientes RHEL 8 y versiones anteriores.

OpenSSL agrega soporte para ajustar los parámetros de las curvas elípticas seguras de Brainpool y brinda protección contra ataques de descifrado RSA basados ​​en el tiempo de las operaciones utilizando variantes del método Bleichenbacher.

SELinux ha agregado la opción virt_qemu_ga_run_unconfined, que permite que el proceso qemu-ga ejecute comandos, como montar, en modo no seguro que estaban restringidos de forma nativa por SELinux.

De los demás cambios que se destacan de esta nueva versión:

• Las implementaciones de los protocolos SCTP (Stream Control Transmission Protocol) y MPTCP (Multipath TCP) se han transferido desde la última versión del kernel de Linux.
• La plataforma ARM64 proporciona soporte completo para cámaras con interfaz USB, adaptadores inalámbricos (Wi-Fi) y Bluetooth.
• Se proporciona soporte completo para tarjetas gráficas discretas Intel Arc A-Series (Alchemist o DG2).
  La implementación del subsistema eBPF está sincronizada con el kernel de Linux 6.3.
• systemd-udevd se ha modificado para permitir nombres permanentes para las interfaces de red InfiniBand.
• Postfix incluye la capacidad de verificar los registros SRV de DNS para determinar el host y el puerto del servidor de correo que se utilizará para transmitir mensajes.
• FUSE3 agrega la capacidad de invalidar una entrada de directorio sin desmontar automáticamente los puntos de montaje asociados con esa entrada.
• Para protegerse contra los ataques de Spectre v2 relacionados con la ejecución especulativa de instrucciones, se agregó el modo AutoIBRS, compatible con CPU AMD a partir de la familia EPYC 9004 Genoa.
• Para los contenedores, es posible utilizar chips virtuales para almacenar claves criptográficas (vTPM), implementados sobre la base de un TPM (Trusted Platform Module) físico común.
• LVM ha agregado soporte para particiones lógicas vmcore para volcados de núcleo generados por el subsistema kdump.
• Se agregó una función del sistema para administrar e instalar unidades systemd.
• Se ha agregado una función del sistema para instalar, configurar, administrar y ejecutar el DBMS PostgreSQL.
• Se ha agregado soporte para definir, cambiar y eliminar ipsets a la función del sistema de firewall.
• Se agregó soporte para herramientas de virtualización para procesadores Intel Xeon Scalable de cuarta generación.
• Podman agrega soporte para contenedores comprimidos usando el algoritmo zstd.
• Se agregó la capacidad de usar Quadlets para generar automáticamente servicios systemd a partir de descripciones de contenedores.
• Capacidades ampliadas para clústeres y sistemas tolerantes a fallas: se agregó soporte para el reemplazo de grupos de particiones que no tienen particiones físicas al agente de activación LVM.
• RHEL Image Builder ha agregado la capacidad de generar archivos OVA para VMware VSphere.
  Se han agregado nuevas opciones «–ipv4-dns-search» y «–ipv6-dns-search»
• Se agregó compatibilidad con el arranque en modo UEFI a las imágenes AMI para entornos de nube AWS EC2.
• Se agregó una característica experimental para la aceleración de hardware de IPsec al mover las operaciones de encapsulación de paquetes al lado de la tarjeta de red.
• La implementación experimental de kTLS (TLS a nivel de kernel) está sincronizada con el kernel 6.3.
• Se agregó soporte para usar kTLS para acelerar GnuTLS.

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

Obtener Red Hat Enterprise Linux

Las imágenes de instalación listas para usar pronto estarán disponibles para los usuarios registrados del Portal de clientes de Red Hat (también puede usar imágenes iso de CentOS Stream 9 para evaluar la funcionalidad).

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

El código del motor Dagor ya es open source

Se dio a conocer la noticia de que Gaijin Entertainment, una desarrolladora de videojuegos húngara, mejor conocida por el simulador de vuelo IL-2 Sturmovik: Birds of Prey y War Thunder, ha tomado la decisión de liberar por completo el código del motor de juegos Dagor Engine, que ha estado en desarrollo durante más de 20 años y se ha utilizado para crear diferentes juegos de shooters 3D.

Y es que hace algunos meses, Gaijin Entertainment abrió partes de Dagor Engine y compartió el código en GitHub y ahora ha anunciado la liberación completa del código fuente, como open source bajo la licencia BSD-3.

Hace unos meses, silenciosamente abrimos algunas partes de nuestro motor Dagor bajo la licencia BSD-3. Esta no es una práctica nueva para nosotros, ni será la última vez que interactuemos con la comunidad de código abierto de esta manera: nuestros lenguajes de programación daScript y Quirrell han estado disponibles en nuestro repositorio de GitHub durante un par de años. Creemos profundamente en el enfoque FOSS y su futuro papel central en el desarrollo de juegos.

El motor es compatible con múltiples plataformas, tales como Windows, Linux, macOS, Nintendo Switch, PlayStation, Xbox, tvOS e iOS. Entre las capacidades del motor: renderizado físicamente correcto, motor de simulación integrado para procesos físicos, colisiones, destrucción y física de vehículos, la capacidad de conectar motores de física externos y entornos dinámicamente destructibles.

Ademas de ello, también cuenta con el soporte para NVIDIA Waveworks, asi como una amplia gama de gráficos efectos y métodos de control de iluminación, sombras dinámicas y suaves, iluminación global, soporte HDR, sonido envolvente, sintetizador de voz, la capacidad de usar el lenguaje de descripción del sombreador HLSL, representación realista de superficies de agua, fuego y humo, simulador de plantas, soporte para esqueletos, animación procedimental e híbrida, subsistema para la creación de juegos multijugador en red y en línea, editores de niveles y recursos.

Recientemente, esta acción ha llamado la atención, lo que ha generado mucha especulación. La decisión de hacer que Dagor Engine sea de código abierto no fue simplemente un acto independiente sino parte de una visión mucho más amplia, y estamos casi listos para darle un primer vistazo a los proyectos en los que hemos estado trabajando durante bastante tiempo. .

Espere nuestro anuncio completo este noviembre. ¡Manténganse al tanto!

Por la parte del código del motor, cabe mencionar que está escrito en C/C++ y como ya se mencionó arriba, el código está abierto bajo la licencia BSD-3. Según las notas del repositorio, el código publicado se importa del repositorio Dagor Engine 4, pero los archivos individuales mencionan la versión 6.5.

Además del motor, el repositorio contiene ejemplos del uso del motor de física, sombreadores de cielo e iluminación global, así como utilidades auxiliares como un visor de recursos, un generador de fuentes, un compilador de sombreadores, utilidades de conversión de formatos, Dargbox, editor de scripts y creador de escenas.

Adicional a ello, vale la pena también mencionar que VK durante la reciente conferencia magistral de Nau Engine, el jefe de desarrollo, Andrey Karsakov, dijo que el equipo utilizará el motor Dagor de código abierto en el motor de juego Nau Engine previamente anunciado.

 «tomar el núcleo de renderizado y los componentes a nivel de sistema del motor Dagor de código abierto». Añadió que esto permitirá a los desarrolladores crear productos con gráficos modernos para la gran mayoría de plataformas.

Se menciona que para construir Nau Engine, se decidió utilizar cmake. Los scripts para la lógica del juego se pueden crear en varios lenguajes de programación, incluidos Lua, Python, C# y TypeScript. El formato glTF se utilizará para datos gráficos, escenas y modelos 3D, permitiendo la portabilidad con Blender, 3DS Max y Maya.

En este mes se iniciaron las pruebas alfa cerradas de la implementación inicial del Nau Engine y está previsto que las pruebas beta abiertas se lancen antes de finales de 2024, mientras que el lanzamiento está previsto para finales de 2025.

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