Esta es una buena pregunta. Investigué este problema hace dos semanas porque estaba fuera. Este error apareció por primera vez en openssh-6.8 en refactoring commit . Básicamente, el problema es que se reemplazó una función que llamó a exit() y la función solo devolvió un valor de error.
if (state->packlen < 1 + 4 ||
state->packlen > PACKET_MAX_SIZE) {
#ifdef PACKET_DEBUG
sshbuf_dump(state->input, stderr);
#endif
logit("Bad packet length %u.", state->packlen);
if ((r = sshpkt_disconnect(ssh, "Packet corrupt")) != 0)
return r;
return SSH_ERR_CONN_CORRUPT; /* <-- this line was added */
}
sshbuf_reset(state->incoming_packet);
Como puede ver en el contexto de versión actual (instantánea arriba) ), esta rama maneja las longitudes de paquetes incorrectos (menores a 5 B y mayores que PACKET_MAX_SIZE ). Esta condición arrojó un mensaje de error, desconectó el paquete y debería tener retorno. Pero el sshpkt_disconnect() podría haber fallado y, en este punto, la ejecución del código continuaría con la función, manejando los búferes recibidos del otro par como válidos, sin verificaciones adicionales. El código se utiliza tanto en el servidor como en el cliente.
Como puede ver, la gravedad de CVSS es bastante inferior a la de otro CVE publicado con la misma versión. Para explotar con éxito este error, tendríamos que diseñar el ajuste de paquetes por encima de la condición (longitud incorrecta), asegurarte de que el sshpkt_disconnect() falla (¿cerrar el socket?) Y esperar ciegamente que sucedan las cosas malas.
La superficie de ataque es mucho más limitada y menos investigada que CVE-2016-0778, donde incluso hubo pruebas de concepto con un servidor diseñado.
También tenga en cuenta que openSSH implementa la separación de privilegios en el servidor, lo que básicamente le brindaría la posible ejecución de código en el elemento secundario limitado en el entorno limitado. Por otro lado, podría usar la ejecución de código en el lado del cliente utilizando un servidor malicioso diseñado, pero por el precio de la desconexión del cliente. El usuario probablemente sea sospechoso, pero no los scripts ( autossh , rsync jobs y similares).