Una característica prevista con implicaciones de seguridad.
El año pasado, investigadores de seguridad de Bishop Fox encontraron e informaron cinco vulnerabilidades en el marco de Ray. Anyscale, la empresa que mantiene el software, decidió parchear cuatro de ellos (CVE-2023-6019, CVE-2023-6020, CVE-2023-6021 y CVE-2023-48023) en la versión 2.8.1, pero afirmó que el El quinto, al que se le asignó CVE-2023-48022, no era realmente una vulnerabilidad, por lo que no se solucionó.
Esto se debe a que CVE-2023-48022 en realidad es causado directamente por el hecho de que el panel de Ray y la API del cliente no implementan controles de autenticación. Por lo tanto, cualquier atacante que pueda llegar a los puntos finales de la API puede enviar nuevos trabajos, eliminar trabajos existentes, recuperar información confidencial y, esencialmente, lograr la ejecución remota de comandos.
El problema es que, como marco cuyo objetivo principal es facilitar la ejecución de cargas de trabajo en clústeres informáticos, la “ejecución remota de comandos” es esencialmente una característica y la falta de autenticación también es una cuestión de diseño. “Debido a la naturaleza de Ray como marco de ejecución distribuida, el límite de seguridad de Ray está fuera del clúster de Ray”, dijo Anyscale en su aviso. “Es por eso que enfatizamos que debe impedir el acceso a su clúster Ray desde máquinas que no sean de confianza (por ejemplo, la Internet pública). Esta es la razón por la que no se ha abordado el quinto CVE (la falta de autenticación integrada en Ray) y por qué, en nuestra opinión, no es una vulnerabilidad, ni siquiera un error”.
La documentación de Ray establece claramente que “Ray espera ejecutarse en un entorno de red seguro y actuar según un código confiable” y que es responsabilidad de los desarrolladores y proveedores de plataformas garantizar esas condiciones para una operación segura. Sin embargo, como hemos visto con otras tecnologías en el pasado que carecían de autenticación de forma predeterminada, los usuarios no siempre siguen las mejores prácticas y, tarde o temprano, las implementaciones inseguras llegarán a Internet. Si bien Anyscale no quiere que los usuarios pongan toda su confianza en un control de aislamiento como la autenticación dentro de Ray en lugar de aislar todo el marco y los clústeres con controles externos, ha decidido trabajar para agregar un mecanismo de autenticación en versiones futuras.
Configuraciones inseguras por defecto
Hasta entonces, sin embargo, es probable que muchas organizaciones sigan exponiendo involuntariamente dichos servidores a Internet porque, según Oligo, muchas guías de implementación y repositorios de Ray, incluidos algunos de los oficiales, vienen con configuraciones de implementación inseguras. Las configuraciones erróneas también se facilitan por el hecho de que, de forma predeterminada, el panel de Ray y la API de Jobs se vinculan a 0.0.0.0, lo que básicamente significa todas las interfaces de red disponibles en un sistema y abre el reenvío de puertos en el firewall para todas ellas.
“Los expertos en IA NO son expertos en seguridad, lo que los deja potencialmente peligrosamente inconscientes de los riesgos muy reales que plantean los marcos de IA”, dijeron los investigadores. “Sin autorización para la API Jobs de Ray, la API puede quedar expuesta a ataques de ejecución remota de código si no sigue las mejores prácticas”.
Fuente Original CSO Online
