Questa è una buona domanda. Ho esaminato questo problema due settimane fa perché era fuori. Questo bug è apparso per la prima volta in openssh-6.8 in commit refactoring . Fondamentalmente il problema è che è stata sostituita la funzione che ha chiamato exit() con la funzione che restituisce solo il valore di errore.
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);
Come puoi vedere nel contesto di versione corrente (istantanea sopra ), questo ramo gestisce le lunghezze del pacchetto errate (inferiori a 5 B e maggiori di PACKET_MAX_SIZE ). Questa condizione ha generato un messaggio di errore, un pacchetto disconnesso e dovrebbe essere restituito. Ma il sshpkt_disconnect() avrebbe potuto fallire e, a questo punto, l'esecuzione del codice avrebbe continuato a funzionare ulteriormente, gestendo i buffer ricevuti dall'altro peer come validi, senza controlli aggiuntivi. Il codice viene utilizzato sia sul server che sul client.
Come vedi, la gravità CVSS è molto inferiore a altro CVE rilasciato con la stessa versione. Per sfruttare con successo questo bug, dovresti creare un pacchetto che soddisfi le condizioni (lunghezza errata), assicurarti che sshpkt_disconnect() fallisca (chiudi il socket?) E ti aspetti ciecamente che le cose malvagie accadano.
La superficie di attacco è molto più limitata e meno investigata rispetto a CVE-2016-0778, dove era persino la prova del concetto con il server creato.
Si noti inoltre che openSSH implementa la separazione dei privilegi sul server, il che darebbe fondamentalmente solo l'eventuale esecuzione di codice nel child net limitato nella sandbox. D'altra parte, è possibile utilizzare l'esecuzione del codice sul lato client utilizzando il server malevolo predisposto, ma al prezzo della disconnessione del client. Probabilmente l'utente sarebbe sospettoso, ma non gli script ( autossh , rsync jobs e simili).