CVE-2018-10933 - Omitir autenticación SSH - Vulnerabilidad libssh

70

Parece que CVE-2018-10933 se lanzó hoy y puede encontrar un resumen aquí en libssh here

Resumen:

  

las versiones 0.6 y posteriores de libssh tienen una vulnerabilidad de omisión de autenticación en el código del servidor. Al presentar al servidor un mensaje SSH2_MSG_USERAUTH_SUCCESS en lugar del mensaje SSH2_MSG_USERAUTH_REQUEST que el servidor esperaría para iniciar la autenticación, el atacante podría autenticar con éxito sin ninguna credencial.

Estoy tratando de entender esto más y su rango de impacto. ¿Los sistemas operativos como Debian, Ubuntu dependen de libssh para SSH y, si lo hacen, significa que cada servidor que expone SSH es vulnerable a este ataque? Además, ¿OpenSSH depende de libssh o son dos implementaciones separadas? Intenté buscar OpenSSH vs libssh pero no pude encontrar lo que estaba buscando. Esta vulnerabilidad parece ser el peor de los escenarios para SSH, así que me sorprende que no haya aparecido en los titulares o que haya explotado. El resumen de esta vulnerabilidad es vago, por lo que estoy buscando información sobre el alcance del impacto y en qué escenarios debería preocuparme.

    
pregunta User0813484 16.10.2018 - 20:17
fuente

3 respuestas

55
  

... ¿OpenSSH se basa en libssh

OpenSSH (que es el demonio SSH estándar en la mayoría de los sistemas) no se basa en libssh.

  

Intenté buscar openssh v.s. libssh ...

En realidad, una búsqueda de openssh libssh me da el primer golpe: OpenSSH / Development que incluye para libssh la siguiente declaración : "... libssh es un proyecto independiente ..."

Además, si se vería afectado OpenSSH, puede estar seguro de que encontrará dicha información en el sitio oficial de OpenSSH, que tiene explícitamente una página sobre Seguridad de OpenSSH .

  

Los sistemas operativos como Debian, Ubunutu confían en libssh para SSH ...

Consulte la documentación oficial de libssh sobre quién la está utilizando (al menos): KDE, GitHub ...

También puede verificar qué paquetes disponibles o instalados en su propio sistema operativo dependen de libssh. p.ej. para Debian y similares (por ejemplo, Ubuntu) esto sería apt rdepends libssh-4 o apt rdepends --installed libssh-4 .

Tenga en cuenta que el uso de libssh no significa necesariamente que el producto sea automáticamente vulnerable. Primero, el problema parece ser relevante solo cuando se utiliza libssh para el servidor SSH y no para el cliente. E incluso en el rol del servidor no está necesariamente afectado, por ejemplo, Github no parece estar afectado a pesar de que utilizan libssh en el rol del servidor.

    
respondido por el Steffen Ullrich 16.10.2018 - 20:35
fuente
11
  

¿Los sistemas operativos como Debian, Ubuntu confían en libssh para SSH y si lo hacen, significa que cada servidor que expone SSH es vulnerable a este ataque?

Los problemas pueden surgir con las aplicaciones que utilizan libssh. Como se indica en el sitio web libssh : "libssh es una biblioteca de C que le permite escribir un programa que usa el SSH protocolo." Por lo tanto, las aplicaciones de usuario que hacen uso de la biblioteca libssh podrían ser vulnerables, no el sistema operativo en sí. Aquí hay algunas aplicaciones que utilizan libssh (del sitio web libssh ):

  • KDE usa libssh para las transferencias de archivos sftp
  • GitHub implementó su servidor git ssh con libssh
  • X2Go es una solución de escritorio remoto para Linux
  

También, ¿OpenSSH depende de libssh o son dos implementaciones separadas?

No, no lo hace. Ellos están separados.

Actualización 2018-10-18: una publicación de blog escrita por el descubridor de vulnerabilidades e incluye una explicación detallada y un código de prueba de concepto (a través de Paramiko) es ya está disponible .

La publicación del blog vinculado a explica que la vulnerabilidad se debe al hecho de que el código en la tabla de despacho de procesamiento de paquetes (en libssh \ src \ packet.c) ejecuta manejadores para SSH2_MSG_USERAUTH_SUCCESS incluso para servidores (incluso si tal mensaje es solo Se supone que debe ser procesado por los clientes). La investigación adicional del código muestra que tal procesamiento erróneo del mensaje en libssh \ src \ auth.c hace que el servidor cambie el estado de la sesión para autenticarse.

También está disponible un código detallado de prueba de concepto, que muestra que se puede actualizar Python Paramiko para enviar el mensaje SSH2_MSG_USERAUTH_SUCCESS en lugar de un mensaje SSH2_MSG_USERAUTH_REQUEST y aprovechar la vulnerabilidad.

Sin embargo, la publicación del blog también establece que:

  

"No todos los servidores libSSH serán necesariamente vulnerables a la omisión de autenticación; ya que la omisión de autenticación configura la máquina de estado libSSH interna para que se autentique sin ofrecer a los devoluciones de llamada de autenticación registrados la oportunidad de ejecutar, los servidores desarrollados con libSSH mantienen una sesión personalizada adicional el estado puede dejar de funcionar correctamente si un usuario se autentica sin que se cree este estado ".

    
respondido por el hft 16.10.2018 - 20:44
fuente
3

Para ver las dependencias de una aplicación a través de la línea de comandos, puede ejecutar el siguiente comando:

ldd / usr / sbin / ssh

Esto mostrará cualquier dependencia de dicha aplicación. Cuando se ejecuta este comando, no muestra libssh, lo que significa que libssh no es parte de OpenSSH.

    
respondido por el Jason Mesker 17.10.2018 - 16:20
fuente

Lea otras preguntas en las etiquetas