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