El Proyecto CentOS anuncio hace poco de manera oficial la disponibilidad de la distribución CentOS Stream 9, que se utiliza como base para la distribución Red Hat Enterprise Linux 9 como parte de un nuevo proceso de desarrollo más abierto.

CentOS Stream es una distribución que se actualiza continuamente y permite el acceso temprano a los paquetes que se están desarrollando para una futura versión de RHEL. CentOS Stream se posiciona como un proyecto upstream para RHEL, lo que permite a terceros participantes controlar la preparación de paquetes para RHEL, proponer sus cambios e influir en las decisiones.

Anteriormente, se utilizó una instantánea de una de las versiones de Fedora como base para una nueva rama de RHEL, que se refinó y estabilizó a puerta cerrada, sin la capacidad de controlar el proceso de desarrollo y las decisiones tomadas. Durante el desarrollo de RHEL 9 basado en la instantánea de Fedora 34 , con la participación de la comunidad, se formó la sucursal CentOS Stream 9, en la cual se está realizando el trabajo preparatorio y se forma la base para una nueva sucursal RHEL significativa.

Principales cambios en CentOS Stream 9

El escritorio se basa en GNOME 40 (GNOME 3.28 incluido en RHEL 8) y la biblioteca GTK 4. En GNOME 40, los escritorios virtuales en el modo Descripción general de actividades están configurados en orientación horizontal y aparecen como un bucle continuo de izquierda a derecha. GNOME utiliza el controlador power-profiles-daemon, que proporciona la capacidad de cambiar sobre la marcha entre el modo de ahorro de energía, el modo de equilibrio de energía y el modo de rendimiento máximo.

Todas las transmisiones de audio se han movido al servidor de medios PipeWire, que ahora es el predeterminado en lugar de PulseAudio y JACK. El uso de PipeWire le permite ofrecer capacidades de procesamiento de audio profesional en una edición de escritorio típica, eliminar la fragmentación y unificar su infraestructura de audio para diferentes aplicaciones.

De forma predeterminada, el menú de inicio de GRUB está oculto si RHEL es la única distribución en el sistema y si el inicio anterior fue exitoso. Para mostrar el menú durante el arranque, simplemente mantenga presionada la tecla Shift o presione la tecla Esc o F8 varias veces.

Los componentes para admitir diferentes idiomas se han trasladado a paquetes de idioma, lo que permite variar el nivel de compatibilidad con los idiomas instalados.

La distribución utiliza una nueva rama de la biblioteca criptográfica OpenSSL 3.0. De forma predeterminada, se habilitan algoritmos criptográficos más modernos y confiables (por ejemplo, el uso de SHA-1 en TLS, DTLS, SSH, IKEv2 y Kerberos está deshabilitado, TLS 1.0, TLS 1.1, DTLS 1.0, RC4, Camellia, DSA, 3DES y FFDHE-1024 están deshabilitados).

El rendimiento de SELinux ha sido significativamente mejorado y con menor consumo de memoria. En /etc/selinux/config, se eliminó el soporte para la configuración «SELINUX=disabled» para deshabilitar SELinux.

La composición incluye un nuevo demonio mptcpd para configurar MPTCP (MultiPath TCP), una extensión del protocolo TCP para organizar una conexión TCP con la entrega de paquetes simultáneamente a lo largo de varias rutas a través de diferentes interfaces de red asociadas a diferentes direcciones IP. El uso de mptcpd hace posible configurar MPTCP sin usar la utilidad iproute2.

Se eliminó el paquete de scripts de red, en su lugar esta NetworkManager para configurar las conexiones de red. El formato de configuración ifcfg todavía es compatible, pero NetworkManager tiene por defecto un formato basado en archivos de claves.

Clang se usa de forma predeterminada para construir el emulador QEMU, lo que permitió que el hipervisor KVM usara algunos mecanismos de protección adicionales, como SafeStack, para protegerse contra las prácticas de explotación de la programación orientada al retorno (ROP).

SSSD (System Security Services Daemon) ha aumentado la granularidad de los registros, por ejemplo, el tiempo de finalización de la tarea ahora se adjunta a los eventos y se refleja el flujo de autenticación. Se agregaron funciones de búsqueda para analizar problemas de configuración y rendimiento.

De los de mas cambios que se destacan:

• Se agregó compatibilidad con VPN WireGuard experimental
• De forma predeterminada, se deniega el inicio de sesión SSH como root.
• Herramientas de administración de filtros de paquetes declaradas obsoletas iptables-nft (utilidad iptables, ip6tables, ebtables y arptables) e ipset. Ahora se recomienda usar nftables para administrar el firewall .
• Se han actualizado el entorno del sistema y las herramientas de montaje.
• GCC 11 se usa para construir paquetes
• La biblioteca estándar de C se ha actualizado a glibc 2.34
• El paquete del kernel de Linux se basa en la versión 5.14
• RPM Batch Manager se ha actualizado a la versión 4.16 con soporte para control de integridad a través de fapolicyd.
• Se completó la migración de la distribución a Python 3.
• De forma predeterminada, se ofrece la rama Python 3.9

Finalmente, cabe mencionar que las compilaciones están preparadas para arquitecturas x86_64, Aarch64 y ppc64le (IBM Power 9+). Además, se declara el soporte para la arquitectura IBM Z (s390x Z14 +), pero las compilaciones para ella aún no están disponibles.

Si quieres conocer mas al respecto, puedes consultar los detalles en el siguiente enlace.

from Linux Adictos https://ift.tt/3pFCs5w
via IFTTT

Se dio a conocer la noticia sobre la identificación de una vulnerabilidad crítica (ya catalogada bajo CVE-2021-43527) en el conjunto de bibliotecas criptográficas NSS (Servicios de seguridad de red) de Mozilla que podría conducir a la ejecución de código malicioso al procesar firmas digitales DSA o RSA-PSS especificadas mediante la DER (Distinguido reglas de codificación).

El problema se manifiesta en aplicaciones que usan NSS para manejar firmas digitales CMS, S/MIME, PKCS#7 y PKCS#12, o al verificar certificados en implementaciones TLS, X.509, OCSP y CRL. La vulnerabilidad podría surgir en varias aplicaciones de cliente y servidor con soporte TLS, DTLS y S / MIME, clientes de correo electrónico y visores de PDF que utilizan la llamada NSS CERT_VerifyCertificate () para verificar firmas digitales.

LibreOffice, Evolution y Evince se mencionan como ejemplos de aplicaciones vulnerables. Potencialmente, el problema también puede afectar proyectos como Pidgin, Apache OpenOffice, Suricata, Curl, entre otros.

Al mismo tiempo, la vulnerabilidad no aparece en Firefox, Thunderbird y Tor Browser, que utilizan una biblioteca mozilla::pkix separada para la verificación, que también es parte de NSS. Los navegadores basados ​​en Chrome (a menos que se hayan compilado específicamente con NSS), que usaron NSS hasta 2015, pero luego se transfirieron a BoringSSL, no se ven afectados por el problema.

La vulnerabilidad se debe a un error en el código de verificación de certificado en el vfy_CreateContext función del archivo secvfy.c. El error se manifiesta tanto cuando el cliente lee el certificado del servidor como cuando el servidor procesa los certificados del cliente.

Al verificar una firma digital codificada en DER, NSS decodifica la firma en un búfer de tamaño fijo y pasa este búfer al módulo PKCS # 11. Durante el procesamiento posterior, para las firmas DSA y RSA-PSS, el tamaño se verifica incorrectamente, lo que conduce a un desbordamiento del búfer asignado para la estructura VFYContextStr , si el tamaño de la firma digital supera los 16384 bits (se asignan 2048 bytes para el búfer, pero no se comprueba que la firma pueda ser más grande).

El código que contiene la vulnerabilidad se remonta a 2003, pero no representó una amenaza hasta la refactorización en 2012. En 2017, se cometió el mismo error al implementar el soporte RSA-PSS. Para llevar a cabo un ataque, no se requiere una generación intensiva en recursos de ciertas claves para obtener los datos necesarios, ya que el desbordamiento ocurre en la etapa previa a la verificación de la validez de la firma digital. La parte de los datos fuera de los límites se escribe en un área de memoria que contiene punteros de función, lo que facilita la creación de exploits de trabajo.

La vulnerabilidad fue identificada por investigadores de Google Project Zero durante experimentos con nuevos métodos de pruebas de fuzzing y es una buena demostración de cómo las vulnerabilidades triviales pueden pasar desapercibidas durante mucho tiempo en un proyecto conocido ampliamente probado.

En cuanto a los principales problemas por los que el problema pasó desapercibido durante mucho tiempo:

• La biblioteca de unidades NSS y las pruebas de fuzzing no se llevaron a cabo en su totalidad, sino a nivel de componentes individuales.
• Por ejemplo, el código para decodificar DER y procesar certificados se verificó por separado; en el curso del fuzzing, bien podría haberse obtenido un certificado, lo que llevó a la manifestación de la vulnerabilidad en cuestión, pero su verificación no alcanzó el código de verificación y el problema no se reveló.
• Durante las pruebas de fuzzing, se establecieron límites estrictos en el tamaño de la salida (10,000 bytes) en ausencia de tales limitaciones en NSS (muchas estructuras en modo normal podrían tener un tamaño de más de 10,000 bytes, por lo tanto, para identificar problemas, un mayor cantidad de datos de entrada necesarios). Para una verificación completa, el límite debería haber sido 2 24 -1 bytes (16 MB), que corresponde al tamaño máximo de un certificado permitido en TLS.
• Concepto erróneo sobre la cobertura del código mediante pruebas fuzzing. El código vulnerable se probó activamente, pero utilizando fuzers, que no pudieron generar los datos de entrada requeridos. Por ejemplo, fuzzer tls_server_target usó un conjunto predefinido de certificados listos para usar, que limitaban la verificación del código de verificación del certificado a solo mensajes TLS y cambios de estado del protocolo.

Finalmente, cabe mencionar que el problema con nombre en código BigSig se ha solucionado en NSS 3.73 y NSS ESR 3.68.1 y las actualizaciones de la solución en forma de paquete ya se han lanzado en las diferentes distribuciones: Debian, RHEL, Ubuntu, SUSE, Arch Linux, Gentoo, FreeBSD, etc.

Si quieres conocer más al respecto, puedes consultar el siguiente enlace.

from Linux Adictos https://ift.tt/3lOQII3
via IFTTT

Hace poco se presentó la liberación de la nueva versión del navegador especializado Tor Browser 11.0.2, el cual está enfocado a garantizar el anonimato, la seguridad y la privacidad. Al usar el navegador Tor, todo el tráfico se redirige solo a través de la red Tor, y es imposible contactar directamente a través de la conexión de red estándar del sistema actual, que no permite rastrear la dirección IP real del usuario.

La nueva versión se sincroniza con el código base de la versión Firefox 91.4.0, que corrige 15 vulnerabilidades, 10 de las cuales están marcadas como peligrosas.

7 de las vulnerabilidades son causadas por problemas de memoria, como desbordamientos de búfer y acceso a áreas de memoria ya liberadas, y pueden conducir potencialmente a la ejecución del código de un atacante al abrir páginas especialmente diseñadas.

Ademas se eliminaron algunas fuentes ttf de la compilación para Linux, cuyo uso provocó la violación de la representación de texto en los elementos de la interfaz en Fedora Linux.

Tambien se menciona que se deshabilitó la configuración «network.proxy.allow_bypass», que controla la actividad de protección contra el uso incorrecto de complementos de API Proxy y que para el transporte obfs4, la nueva puerta de enlace «deusexmachina» está habilitada de forma predeterminada.

Sobre el ataque a Tor

Por otra parte, tambien cabe señalar la publicación de un nuevo informe sobre posibles intentos de realizar ataques para desanonimizar a los usuarios de Tor asociados al grupo KAX17, el cual es asignado por un correo electrónico de contacto falso específico en los parámetros del nodo.

Durante septiembre y octubre, el proyecto Tor bloqueó 570 nodos potencialmente maliciosos. En su apogeo, el grupo KAX17 logró llevar el número de nodos controlados en la red Tor a 900 alojados por 50 proveedores diferentes, lo que corresponde a aproximadamente el 14% del número total de relés (en comparación, en 2014 los atacantes lograron ganar control sobre casi la mitad de los relés Tor, y en 2020 más del 23,95% de los nodos de salida).

¡Hola, todos!

Algunos de ustedes habrán notado que hay una caída visible de retransmisiones en nuestro sitio web de consenso sobre salud. [1] La razón de esto es que ayer echamos de la red aproximadamente 600 relés sin salida. De hecho, solo una pequeña fracción de ellos tenía la bandera de guardia, por lo que la gran mayoría eran relevos intermedios. No tenemos ninguna evidencia de que estos relés estuvieran haciendo algún ataque, pero hay ataques posibles que los relés podrían realizar desde la posición media. Por lo tanto, decidimos eliminar esos relés por el bien de la seguridad de nuestros usuarios.

Si bien ya estábamos rastreando algunos de los relés por un tiempo, un cypherpunk también informó de forma independiente una gran parte de ellos y nusenu ayudó a analizar los datos. Gracias a los dos de nuestro lado.

La colocación de una gran cantidad de nodos controlados por un operador permite a los usuarios desanonimizar mediante un ataque de clase Sybil, que se puede llevar a cabo si los atacantes tienen control sobre el primer y último nodos de la cadena de anonimización. El primer nodo de la cadena Tor conoce la dirección IP del usuario, y el último conoce la dirección IP del recurso solicitado, lo que permite desanonimizar la solicitud agregando una determinada etiqueta oculta en el lado del nodo de entrada al paquete de encabezados que permanecen sin cambios a lo largo de toda la cadena de anonimización y analizando esta etiqueta para el lado del nodo de salida. Con nodos de salida controlados, los atacantes también pueden realizar cambios en el tráfico no cifrado, como eliminar redireccionamientos a variantes HTTPS de sitios e interceptar contenido no cifrado.

De acuerdo a representantes de la red Tor, la mayoría de los nodos retirados en la caída se utilizaron sólo como nodos intermedios, no se utiliza para procesar las peticiones entrantes y salientes. Algunos investigadores señalan que los nodos pertenecían a todas las categorías y la probabilidad de golpear el nodo de entrada controlado por el grupo KAX17 era del 16%, y en la salida, del 5%. Pero incluso si este es el caso, la probabilidad general de que un usuario golpee simultáneamente los nodos de entrada y salida de un grupo de 900 nodos controlados por KAX17 se estima en 0.8%. No hay evidencia directa del uso de nodos KAX17 para realizar ataques, pero tales ataques no están excluidos.

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

from Linux Adictos https://ift.tt/31FvhSE
via IFTTT

Se comenta que es una de las distribuciones favoritas para los usuarios que dan el salto desde Windows, pero entre gustos no hay nada escrito. Lo que sí se ha escrito es una nota hablando del lanzamiento de Zorin OS Lite 16, lo que ha llegado casi cuatro meses después de la 16ª versión normal. «Lite» viene de «ligero», y esta versión ha llegado con Xfce 4.16, aunque con un tema muy parecido al de la edición GNOME.

El Xfce 4.16 de Zorin OS Lite 16 nos permite cambiar de tema, activar el modo oscuro o elegir un color de énfasis desde el menú de apariencia. La opción de apariencia también ha recibido mejoras para permitirnos personalizar mejor la experiencia del sistema operativo. Pero la etiqueta de Lite también significa que hay cosas que no están disponibles, como el modo gelatina. No se puede tener todo.

Otras novedades destacadas de Zorin OS 16 Lite

• Linux 5.11.
• Basado en Ubuntu 20.04.3, soportado hasta abril de 2025.
• Rhythmbox.
• Nuevos fondos de pantalla, aunque algunos estarán disponibles sólo para la versión Pro.
• Capas de escritorio (temas) extra para la edición Pro.
• Vista previa en la barra de tareas, como las que ya vemos en Plasma o en Windows 10.
• Flathub activado por defecto.
• Nueva aplicación para grabar sonidos.
• Firefox tiene la telemetría desactivada.
• El gestor de archivos Thunar ha recibido las sutiles mejoras habituales y se integra con el resto del diseño. Debería ser posible reproducir videos tras la instalación de cero usando el reproductor de vídeo parole.

«En general, el equipo de Zorin OS ha hecho un magnífico trabajo al trasladar el bonito diseño y la facilidad de uso de Zorin OS 16 a su edición lite. Es posible que ni siquiera te des cuenta de que estás usando el entorno de escritorio Xfce en su mayor parte».

Zorin OS 16 Lite ya se puede descargar desde este enlace.

from Linux Adictos https://ift.tt/3EJVvlm
via IFTTT