it-swarm-eu.dev

CVE-2018-10933 - Bypass SSH Authentication - vulnerabilità libssh

Sembra che CVE-2018-10933 sia stato appena rilasciato oggi e puoi trovare un riepilogo qui da libssh qui

Sommario:

le versioni libssh 0.6 e successive hanno una vulnerabilità di bypass di autenticazione nel codice del server. Presentando al server un messaggio SSH2_MSG_USERAUTH_SUCCESS al posto del messaggio SSH2_MSG_USERAUTH_REQUEST che il server si aspetterebbe di avviare l'autenticazione, l'utente malintenzionato potrebbe autenticare correttamente senza alcuna credenziale.

Sto cercando di capire di più questo e la sua gamma di impatto. I sistemi operativi come Debian, Ubuntu si basano su libssh per SSH e se ciò significa che ogni server che espone SSH è vulnerabile a questo attacco? Inoltre, OpenSSH si basa su libssh o sono due implementazioni separate? Ho provato a cercare OpenSSH vs libssh ma non sono riuscito a trovare quello che cercavo. Questa vulnerabilità sembra lo scenario peggiore per SSH, quindi sono solo sorpreso che non abbia fatto notizia o fatto saltare in aria. Il riassunto di questo vuln è vago, quindi sto cercando informazioni sulla gamma di impatto e in quali scenari dovrei essere preoccupato.

71
User0813484

... OpenSSH si affida a libssh

OpenSSH (che è il demone SSH standard sulla maggior parte dei sistemi) non si basa su libssh.

Ho provato a cercare openssh v.s. libssh ...

In realtà, una ricerca di openssh libssh mi dà come primo successo: OpenSSH/Sviluppo che include per libssh la seguente dichiarazione : " ... libssh è un progetto indipendente ... "

Inoltre, se OpenSSH ne risentisse, puoi essere certo di trovare tali informazioni sul sito ufficiale di OpenSSH, che ha esplicitamente una pagina su OpenSSH Security .

I sistemi operativi come Debian, Ubunutu si basano su libssh per SSH ...

Vedi la documentazione ufficiale di libssh su chi lo sta usando (almeno): KDE, GitHub ...

Puoi anche controllare quali pacchetti disponibili o installati sul tuo sistema operativo dipendono da libssh. per esempio. per Debian e simili (es. Ubuntu) questo sarebbe apt rdepends libssh-4 o apt rdepends --installed libssh-4.

Si noti che l'uso di libssh non significa necessariamente che il prodotto sia automaticamente vulnerabile. Innanzitutto, il problema sembra essere rilevante solo quando si utilizza libssh per server non client SSH. E anche nel ruolo del server non è necessariamente interessato, ad esempio Github sembra non essere interessato anche se usano libssh nel ruolo del server.

56
Steffen Ullrich

I sistemi operativi come Debian, Ubuntu si affidano a libssh per SSH e se ciò significa che ogni server che espone SSH è vulnerabile a questo attacco?

I problemi possono sorgere con applicazioni che usano libssh. Come indicato sul libssh sito web : "libssh è una libreria C che consente di scrivere un programma che utilizza il protocollo SSH." Pertanto, sono le applicazioni utente che fanno uso della libreria libssh che potrebbero essere vulnerabili, non il sistema operativo stesso. Ecco alcune applicazioni che usano libssh (dal libssh sito web ):

  • KDE usa libssh per i trasferimenti di file sftp
  • GitHub ha implementato il proprio server git ssh con libssh
  • X2Go è una soluzione di desktop remoto per Linux

Inoltre, OpenSSH si basa su libssh o sono due implementazioni separate?

No, non lo fa. Sono separati.


Aggiornamento 18-10-2018: un post sul blog scritto dallo scopritore della vulnerabilità e comprendente una spiegazione dettagliata e un codice di prova di concetto (tramite Paramiko) è ora disponibile .

Il post sul blog collegato spiega che la vulnerabilità deriva dal fatto che il codice nella tabella di invio dell'elaborazione dei pacchetti (in libssh\src\packet.c) esegue gestori per SSH2_MSG_USERAUTH_SUCCESS anche per i server (anche se si suppone che tale messaggio sia solo elaborato dai clienti). Un'ulteriore analisi del codice mostra che tale elaborazione errata del messaggio in libssh\src\auth.c fa sì che il server cambi lo stato della sessione in autenticato!

È inoltre disponibile un codice dettagliato di prova di concetto, che mostra che python Paramiko può essere aggiornato per inviare il messaggio SSH2_MSG_USERAUTH_SUCCESS al posto di un messaggio SSH2_MSG_USERAUTH_REQUEST e sfruttare la vulnerabilità.

Tuttavia, il post sul blog afferma anche che:

"Non tutti i server libSSH saranno necessariamente vulnerabili al bypass di autenticazione; poiché il bypass di autenticazione imposta la macchina a stati libSSH interna su autenticata senza mai dare a callback di autenticazione registrati l'opportunità di eseguire, i server sviluppati usando libSSH che mantengono uno stato di sessione personalizzato aggiuntivo potrebbero non funzionare per funzionare correttamente se un utente viene autenticato senza che questo stato venga creato. "

11
hft

Per visualizzare le dipendenze di un'applicazione tramite la riga di comando è possibile eseguire il comando seguente:

ldd/usr/sbin/ssh

Ciò mostrerà qualsiasi dipendenza di detta applicazione. Quando questo comando viene eseguito, non mostra libssh che significa che libssh non fa parte di OpenSSH.

3
Jason Mesker