AlmaLinux da cachetada con guante blanco a Red Hat, ya que tuvo que aceptar una corrección de vulnerabilidad
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.