AlmaLinux hace recapacitar a Red Hat después de negarse a aceptar un parche

A los desarrolladores de AlmaLinux se les ha presentado la oportunidad de poder demostrar a Red Hat que no son «una amenaza» que dedica únicamente a duplicar otros desarrollos y crear una reconstrucción simple (esto en referencia al comentario realizado por Red Hat por restringir el acceso al código de RHEL)

Y es que justamente poco después de haber realizado el anuncio en el cambio a un nuevo modelo de mantenimiento de distribución, que permite la aplicación de sus propios parches, los desarrolladores de AlmaLinux corrigieron la vulnerabilidad en el paquete iperf3 (ya catalogada bajo CVE-2023-38403 ) e intentaron enviar la corrección preparada a CentOS Stream, ya que la vulnerabilidad permaneció sin parches en RHEL y CentOS Stream.

De manera inicial Red Hat se negó a aceptar la solución, citando la regla de que «solo se pueden solucionar los problemas importantes», ya que para los desarrolladores de Red Hat, dicha vulnerabilidad no era importante y no presentaba un riesgo «importante» como para marcalo como»prioritario» pues otro de sus comentarios fue que las soluciones este tipo de problemas se incluyen en los paquetes solo cuando es necesario, debido a solicitudes de clientes o necesidades comerciales.

Gracias por la contribución. En este momento no planeamos abordar esto en RHEL, pero lo mantendremos abierto para su evaluación en función de los comentarios de los clientes.

Poco después de «la evaluación» por parte de Red Hat de la solución a la vulnerabilidad, el representante de Alma Linux expresó desconcierto, ya que se envió un parche listo para solucionar el problema para su inclusión en CentOS Stream y:

Red Hat no estaba obligado a crear una solución por sí mismo, sino que solo necesitaba revisar el cambio final aceptado en el base de código del proyecto iperf .

El desarrollador de Alma Linux tampoco estuvo de acuerdo en catalogar que la vulnerabilidad es menor, ya que el error corregido conduce a un desbordamiento de enteros y corrupción de la memoria del proceso cuando se pasa un valor incorrecto al campo de tamaño de datos.

Y es que menciona el desarrollador de AlmaLinux que como tal la vulnerabilidad en iperf3, permite enviar un mensaje especialmente diseñado y causar daños en la memoria (es posible un ataque tanto del cliente al servidor como del servidor al cliente). Esto se debe a que iperf3 está diseñado para probar el rendimiento de la red, utiliza un modelo cliente-servidor en el que el cliente envía una solicitud con parámetros al proceso del servidor a través de una conexión TCP, y el servidor realiza la prueba y devuelve el resultado.

En la práctica, la vulnerabilidad permite a un atacante atacar servidores iperf3 de acceso público existentes o crear su propio servidor y atacar a los usuarios que se conectan a través de él. Se supone que la explotación de la vulnerabilidad se limita a bloquear el proceso, pero incluso en este caso, es necesario reparar la capacidad de provocar que el proceso del servidor iperf3 se bloquee de forma remota en servidores de acceso público.

En respuesta, un empleado de Red Hat explicó que el asunto no se limita a un parche terminado y que el desarrollo de una solución es solo una de las etapas en la preparación de una actualización del paquete: debe asegurarse de que la solución pase el control de calidad y luego de ser aplicado en el paquete, no conduce a cambios regresivos.

Nos comprometemos a abordar los problemas de seguridad críticos e importantes definidos por Red Hat. Las vulnerabilidades de seguridad con gravedad baja o moderada se abordarán a pedido cuando existan requisitos del cliente u otros requisitos comerciales para hacerlo.

Por lo tanto, solo las vulnerabilidades críticas e importantes se corrigen sin falta, y los problemas con un nivel de gravedad bajo y medio se resuelven según surge la necesidad.

Finalmente, cabe mencionar que después de la discusión, el equipo de seguridad de Red Hat reconsideró su posición, clasificó el problema como importante, aceptó el parche y lanzó una actualización del paquete para corregir la vulnerabilidad.

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

OpenSSH es un conjunto de aplicaciones que permiten realizar comunicaciones cifradas a través de una red, usando el protocolo SSH

Se dio a conocer el lanzamiento de la nueva versión de OpenSSH 9.4, versión en la cual se han implementado una serie de correcciones y pequeñas mejoras de las cuales se destaca el soporte para etiquetas de configuración soporte para extensiones KRL y mas.

Para quienes desconocen de OpenSSH (Open Secure Shell) deben saber que este es un conjunto de aplicaciones que permiten realizar comunicaciones cifradas a través de una red, usando el protocolo SSH. Fue creado como una alternativa libre y abierta al programa Secure Shell, que es software propietario.

Principales novedades de OpenSSH 9.4

En esta nueva versión que se presenta de la implementación OpenSSH 9.4 una de sus principales novedades es el soporte para etiquetas de configuración a ssh mediante la directiva «Tag»  y una operación de coincidencia «Match tag» al archivo de configuración ssh_config para permitir el uso de etiquetas para definir condiciones de selección para un bloque de configuración específico.

Otro de los cambios que se destaca de esta nueva versión es que sshd, las directivas AuthorizedPrincipalsCommand y AuthorizedKeysCommand admiten dos secuencias adicionales, las cuales son «%- y %D» para sustituir la dirección de la puerta de enlace a través de la cual se enruta la sesión actual y «%C» para sustituir las direcciones y los números de puerto del lado local y remoto de la conexión

Ademas de ello, tambien se destaca que en esta nueva versión de OpenSSH 9.4 se elimina la compatibilidad con versiones anteriores de libcrypto. Con lo cual a partir de OpenSSH 9.4 se requiere versiones superiores a LibreSSL 3.1.0 y OpenSSL 1.1.1.

Tambien otro de los cambios que causan incompatibilidad y como una forma adicional de bloquear la vulnerabilidad asociada con la capacidad de cargar módulos PKCS # 11 en ssh-agent, está prohibido especificar rutas relativas e incompletas a los módulos (anteriormente, la función dlopen buscaba un módulo por nombre en el directorio de la biblioteca).

Por otra parte, se destaca que se agregó el soporte para conectar extensiones en formato KRL a ssh, sshd y ssh-keygen. Las extensiones en sí aún no están disponibles en esta etapa de desarrollo.

Ademas, en la utilidad ssh-keygen predeterminada, la cantidad de rondas en la función bcrypt se incrementó en un 50 % al generar claves para el cifrado de archivos simétricos con claves protegidas con contraseña.

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

• La utilidad ssh permite la redirección a otro host de socket Unix usando el comando «ssh -W».
• Se agregó la operación «match localnetwork» a ssh lo que permite hacer coincidir con las direcciones de las interfaces de red disponibles y puede usarse para variar la configuración efectiva del cliente según la ubicación de la red.
• sshd proporciona un reemplazo para la función SELinux matchpathcon(), que está en desuso.
• Solucion de problemas de compilación para el módulo de proveedor sk-dummy.so FIDO
  utilizado en algunas pruebas.
• ssh-agent mejora el aislamiento entre los módulos PKCS#11 cargados
  mediante la ejecución de ssh-pkcs11-helpers independientes para cada proveedor cargado.
• En sshd, ssh y ssh-keygen se elimina la compatibilidad residual con las firmas KRL. Esta
  versión elimina el código parcialmente implementado para verificar los KRL.
• ssh-keygen corrige que «no comment» no se muestra cuando se ejecuta `ssh-keygen -l` en varias teclas donde una tiene un comentario y otras teclas siguientes no.
• Se ajusto la lógica ftruncate() para manejar servidores que reordenan solicitudes. Anteriormente, si el servidor reordenaba las solicitudes, entonces el archivo resultante se truncaría por error.

Finalmente si estás interesado en conocer más al respecto sobre esta nueva versión, puedes consultar los detalles dirigiéndote al siguiente enlace.

¿Como instalar OpenSSH 9.4 en Linux?

Para quienes estén interesados en poder instalar esta nueva versión de OpenSSH en sus sistemas, de momento podrán hacerlo descargando el código fuente de este y realizando la compilación en sus equipos.

Esto es debido a que la nueva versión aún no se ha incluido dentro de los repositorios de las principales distribuciones de Linux. Para obtener el código fuente, puedes hacer desde el siguiente enlace.

Hecha la descarga, ahora vamos a descomprimir el paquete con el siguiente comando:

tar -xvf openssh-9.4.tar.gz

Entramos al directorio creado:

cd openssh-9.4

Y podremos realizar la compilación con los siguientes comandos:

./configure --prefix=/opt --sysconfdir=/etc/ssh
make
make install

from Linux Adictos https://ift.tt/7pkQSRf
via IFTTT

Lo confieso, a veces me equivoco. Durante mucho tiempo fui un ferviente defensor de la incorporación de las empresas de software al ecosistema del software libre. Pero, OpenELA es una pésima noticia y la demostración de mi error.

En mi defensa, no son Microsoft o Apple las que están haciendo lo de adaptar, extender y extinguir sino empresas de larga relación con el código abierto como Red Hat, IBM, Oracle, SUSE o Google.

Por qué OpenELA es una pésima noticia

Mi compañero Darkcrizt escribió bastante sobre las recientes decisiones de Red Hat de cerrar el acceso a sus repositorios y cómo respondieron los proyectos de código abierto perjudicados.

La última movida fue la creación de la Open Enterprise Linux Alliance.

El anuncio, publicado el 10 de agosto de 2023 dice concretamente que:

CIQ, Oracle y SUSE anunciaron hoy su intención de formar Open Enterprise Linux Association (OpenELA), una asociación comercial colaborativa para fomentar el desarrollo de distribuciones compatibles con Red Hat Enterprise Linux (RHEL) al proporcionar código fuente Enterprise Linux (EL) abierto y gratuito.

Sobre las metas y plazos del proyecto se explica:

A partir de finales de este año, OpenELA proporcionará las fuentes necesarias para que existan versiones posteriores compatibles con RHEL, con un enfoque inicial en las versiones EL8, EL9 y posiblemente EL7 de RHEL. El proyecto se compromete a garantizar la disponibilidad continua de las fuentes de OpenELA para la comunidad de forma indefinida.

Los principios básicos de OpenELA, que reflejan el espíritu del proyecto, incluyen el pleno cumplimiento de este estándar existente, actualizaciones rápidas y soluciones seguras, transparencia, comunidad y garantizar que el recurso siga siendo gratuito y redistribuible para todos.

Suena fantástico, al menos si eres una compañía que usa Red Hat en su centro de cómputos, un prestador de servicios que no quiere pagar las licencias de Red Hat o una empresa que quiere sacarle mercado a Red Hat por precio o por servicios adicionales.

Pero, no es una buena noticia para el ecosistema Linux.

Estándares acordados y de facto

Hace unos cuantos años, cuando todavía la empresa desarrolladora del navegador Opera estaba en Noruega, un fabricante de hardware les prestó un servidor para que evaluaran la compra.

El encargado de hacerlo se encontró con que no podía entrar a la interfaz web de configuración, revisando el código descubrió que había una instrucción específica que bloqueaba el acceso al navegador Opera.

En aquella época Internet Explorer tenía el dominio casi total del mercado y un absoluto desprecio por los estándares de la W3C. Muchos desarrolladores simplemente se limitaban a bloquear a otros navegadores no compatibles con las tecnologías web de Microsoft.

Es decir que Internet Explorer era un estándar de facto.

Los estándares acordados son aquellos en los que la comunidad se pone de acuerdo con las especificaciones. Algunos ejemplos son HTM, Epub u ODF.

En un proceso conocido como coo-petencia las empresas y organizaciones colaboran para crear y difundir un estándar y compiten por ofrecer el mejor producto compatible con ese estándar.

No es el caso.

Adoptar, extender y extinguir

Adoptar, extender y extinguir es una estrategia para lograr el monopolio en la industria del software. Se compone de los siguientes pasos:

1. Adoptar: Se anuncia el apoyo a un determinado proyecto comunitario o estándar y se le asignan recursos y empleados. Red Hat lo hizo con muchos proyectos de código abierto como GNOME o CentOS.
2. Extender: Se usa el poder que da asignar el recurso y personal a esos proyectos para imponer tecnologías de desarrollo propio en lugar de alternativas. Por ejemplo, Wayland en lugar de X11 o Flatpak en lugar de Appimage.
3. Extinguir: A través de organizaciones controladas directa o indirectamente se logra que las tecnologías del competidor se vuelvan irrelevantes y este deba abandonarlas o hacer más lento su desarrollo. Unity, MIr, Snap.

OpenELA es una mala noticia porque lo que hace es convertir a Red Hat Enterprise Linux en el estándar de facto para las distribuciones empresariales.  Algo parecido a lo que sucedió con Chrome cuando casi todos los navegadores adoptaron su motor de búsqueda como base.

¿Necesitamos un estándar para distribuciones empresariales? Probablemente sí, pero tiene que construirse en base a las mejores tecnologías existentes y no a los intereses comerciales de tres empresas.

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