¿Qué tan explotable es el problema reciente de UseRoaming SSH?

Como dijo Steve Sether, esto no es un ataque del hombre en el medio .

¿Qué tan peligroso es?

1. En algunos casos, los ataques de desbordamiento de búfer son posibles.
2. Sus claves SSH privadas pueden ser filtradas a un atacante.

Según la página:

  

El roaming SSH permite a un cliente, en caso de que se interrumpa una conexión SSH   inesperadamente, para reanudarlo más tarde, siempre que el servidor también   lo apoya El servidor OpenSSH no admite roaming, pero el cliente OpenSSH lo admite (aunque no está documentado) y está habilitado por   predeterminado.

Para empezar, esta función está habilitada de forma predeterminada en OpenSSH. Peor aún, no está documentado en la página de manual ssh_config(5) .

Tenga en cuenta que esto es dos exploits:

1. CVE-2016-0777
   • Una fuga de información (divulgación de memoria) puede ser explotada por un pícaro Servidor SSH para engañar a un cliente para que filtre datos confidenciales de la memoria del cliente, incluidas, por ejemplo, las claves privadas.
2. CVE-2016-0778
   • Un desbordamiento de búfer (que conduce a la pérdida del descriptor de archivo), también puede ser explotado por un servidor SSH malicioso, pero debido a otro error en el código posiblemente no sea explotable, y solo bajo ciertas condiciones (no la configuración predeterminada), cuando se utiliza ProxyCommand, ForwardAgent o ForwardX11.

Con respecto al ataque de desbordamiento de búfer, tenga en cuenta que solo es vulnerable en ciertas condiciones, cuando tiene ProxyCommand, y ForwardAgent o ForwardX11 habilitados. Esas son opciones no predeterminadas, por lo que si bien es posible que no se explote en la mayoría de los casos, es posible .

En el caso de un ataque exitoso de desbordamiento de búfer, supongamos que todo lo accesible por el cliente SSH está violado.

Más información

Leería el Análisis de Qualys . Este documento explicará este ataque con gran detalle mucho mejor que la mayoría de nosotros, incluido yo mismo.

  

podría causar la ejecución remota de código

No hay ejecución remota de código. Ningún hombre en el medio, ya que fue aclarado por Mark. Todo se explica en el Análisis de Qualys como ya vinculado.

Pero en resumen:

Lo vulnerable es la implementación de la función de itinerancia en el cliente . El cliente almacena el búfer de no enviar bytes si se suspende la conexión. El servidor vulnerable y mal diseñado puede forzar al cliente a reenviar más de lo que está en el búfer y, por lo tanto, podría obtener su clave privada, si realmente está almacenada en algunas direcciones cercanas (debería no estar en caso normal).

El análisis se presenta en versión específica (openssh-6.4), que casi no se usa en la actualidad y la mayoría de los casos de uso no son directamente aplicables a las versiones utilizadas actualmente. Además, algunos de los problemas son específicos de los sistemas BSD, donde la puesta a cero de la memoria no funcionó como se esperaba. No logré obtener ninguna de las claves de los sistemas actuales que tenía.

El mayor problema es lo que incluso existió, característica no documentada , que era vulnerable en tal forma. Y que estuvo allí durante tanto tiempo (introducido en 2004) y que fue activado de forma predeterminada. Esto podría haber sido mal utilizado en el pasado, pero no sin el conocimiento del usuario (si la sesión fue interactiva). Si pudieras ver

[connection suspended, press return to resume]

Supongo que sospecharías un poco.