🚨 Una vulnerabilidad que llevaba 10 años activa: introduce una contraseña de entre 257 y 1024 bytes y podrás iniciar sesión en el servidor de otra persona
Grupo: 邀请您加入我的群组 悟空粉丝群
El 5 de noviembre, OpenSSH y Alpine Linux publicaron una solución. Al día siguiente, Changpeng Zhao advirtió en X a los administradores de sistemas: "Esta vulnerabilidad de OpenSSH en Alpine Linux lleva 10 años existiendo. Si aún no has instalado el parche, hazlo cuanto antes."
También aclaró que esto no significa que Binance haya sido vulnerada mediante este fallo.
📊 Lo más interesante es la cadena técnica: investigadores descubrieron que, en musl libc, la biblioteca utilizada por Alpine, la función hash devuelve un asterisco cuando la contraseña supera el límite de 256 bytes. Además, cuando OpenSSH comprueba una "cuenta sin contraseña", puede reutilizar la sal de otra cuenta local.
Cada comportamiento tiene sentido por separado, pero al combinarse se produce el problema: el asterisco devuelto coincide con el que indica que el "campo de contraseña está vacío", por lo que basta una sola conexión para superar la autenticación, sin tener que probar contraseñas repetidamente.
🔸 Las condiciones no son ni demasiado exigentes ni demasiado comunes: hay que usar OpenSSH sin tener PAM habilitado, tener activa la autenticación mediante contraseña, conocer el nombre de usuario cuyo campo de contraseña contiene un asterisco y que haya otra cuenta en la máquina con un hash SHA-256 o SHA-512. Quienes usan PAM, desactivan el inicio de sesión con contraseña o no ejecutan SSH en contenedores no se ven afectados.
💡 Lo que realmente merece atención no es que "haya otra vulnerabilidad", sino cómo se originó: no se trata de un error en una línea de código, sino de que los comportamientos predeterminados, razonables por separado, de dos componentes coincidieron en un caso límite. El límite de musl proviene de cambios realizados entre 2012 y 2016; OpenSSH empezó a reutilizar la sal en julio de 2016 para corregir otro problema. Ambos cambios eran correctos por separado, pero al coincidir permitieron eludir la autenticación.
⚠️ El alcance va más allá de Alpine: también están afectadas otras distribuciones que usan musl libc, incluidas algunas configuraciones de OpenWrt, Buildroot y Yocto. OpenWrt usa Dropbear de forma predeterminada, así que no se ve afectado.
📌 Si ejecutas nodos, validadores o servicios propios, esta semana solo tienes que comprobar una cosa: que OpenSSH en tu servidor tenga instalada la versión corregida.
¿Quién se encarga de los parches en tu servidor?
Haz clic en el avatar para ver la transmisión en directo y únete a mi grupo de fans para recibir estrategias diarias 🚀
#公链 #DeFi
Grupo: 邀请您加入我的群组 悟空粉丝群
El 5 de noviembre, OpenSSH y Alpine Linux publicaron una solución. Al día siguiente, Changpeng Zhao advirtió en X a los administradores de sistemas: "Esta vulnerabilidad de OpenSSH en Alpine Linux lleva 10 años existiendo. Si aún no has instalado el parche, hazlo cuanto antes."
También aclaró que esto no significa que Binance haya sido vulnerada mediante este fallo.
📊 Lo más interesante es la cadena técnica: investigadores descubrieron que, en musl libc, la biblioteca utilizada por Alpine, la función hash devuelve un asterisco cuando la contraseña supera el límite de 256 bytes. Además, cuando OpenSSH comprueba una "cuenta sin contraseña", puede reutilizar la sal de otra cuenta local.
Cada comportamiento tiene sentido por separado, pero al combinarse se produce el problema: el asterisco devuelto coincide con el que indica que el "campo de contraseña está vacío", por lo que basta una sola conexión para superar la autenticación, sin tener que probar contraseñas repetidamente.
🔸 Las condiciones no son ni demasiado exigentes ni demasiado comunes: hay que usar OpenSSH sin tener PAM habilitado, tener activa la autenticación mediante contraseña, conocer el nombre de usuario cuyo campo de contraseña contiene un asterisco y que haya otra cuenta en la máquina con un hash SHA-256 o SHA-512. Quienes usan PAM, desactivan el inicio de sesión con contraseña o no ejecutan SSH en contenedores no se ven afectados.
💡 Lo que realmente merece atención no es que "haya otra vulnerabilidad", sino cómo se originó: no se trata de un error en una línea de código, sino de que los comportamientos predeterminados, razonables por separado, de dos componentes coincidieron en un caso límite. El límite de musl proviene de cambios realizados entre 2012 y 2016; OpenSSH empezó a reutilizar la sal en julio de 2016 para corregir otro problema. Ambos cambios eran correctos por separado, pero al coincidir permitieron eludir la autenticación.
⚠️ El alcance va más allá de Alpine: también están afectadas otras distribuciones que usan musl libc, incluidas algunas configuraciones de OpenWrt, Buildroot y Yocto. OpenWrt usa Dropbear de forma predeterminada, así que no se ve afectado.
📌 Si ejecutas nodos, validadores o servicios propios, esta semana solo tienes que comprobar una cosa: que OpenSSH en tu servidor tenga instalada la versión corregida.
¿Quién se encarga de los parches en tu servidor?
Haz clic en el avatar para ver la transmisión en directo y únete a mi grupo de fans para recibir estrategias diarias 🚀
#公链 #DeFi
