CVE-2018-10933 - Ignora autenticazione SSH - vulnerabilità di libssh

70

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

Sommario:

libssh versions 0.6 and above have an authentication bypass vulnerability in the server code. By presenting the server an SSH2_MSG_USERAUTH_SUCCESS message in place of the SSH2_MSG_USERAUTH_REQUEST message which the server would expect to initiate authentication, the attacker could successfully authentciate without any credentials.

Sto cercando di capirlo di più e il suo raggio d'azione. I sistemi operativi come Debian, Ubuntu si basano su libssh per SSH e se lo fanno 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 ho trovato quello che stavo cercando. Questa vulnerabilità suona come lo scenario peggiore per SSH, quindi sono semplicemente sorpreso che non abbia fatto notizia o abbia fatto esplodere. Il riassunto di questo vuln è vago, quindi sto cercando qualsiasi informazione sulla gamma di impatto e in quali scenari dovrei essere preoccupato.

    
posta User0813484 16.10.2018 - 20:17
fonte

3 risposte

55

... does OpenSSH rely on libssh

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

I tried looking for openssh v.s. libssh ...

In realtà, una ricerca per openssh libssh mi dà come prima hit: OpenSSH / Development che include per libssh la seguente dichiarazione : "... libssh è un indipendente progetto ..."

Inoltre, se OpenSSH fosse interessato, puoi sicuramente trovare tali informazioni sul sito ufficiale di OpenSSH, che ha esplicitamente una pagina su OpenSSH Security .

Do Operating Systems like Debian, Ubunutu rely on libssh for 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 SO dipendono da libssh. per esempio. per Debian e simili (ad esempio 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 il server SSH e non per il client. E anche nel ruolo del server non è necessariamente influenzato, ad esempio Github sembra non essere interessato anche se usano libssh in il ruolo del server.

    
risposta data 16.10.2018 - 20:35
fonte
11

Do Operating Systems like Debian, Ubuntu rely on libssh for SSH and if they do does that mean every server exposing SSH is vulnerable to this attack?

I problemi possono sorgere con le applicazioni che usano libssh. Come indicato sul libssh sito web : "libssh è una libreria C che ti permette di scrivere un programma che usa l'SSH protocollo." Pertanto, sono le applicazioni utente che fanno uso della libreria libssh che potrebbe essere vulnerabile, 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 Desktop remoto per Linux

Also, does OpenSSH rely on libssh or are they two separate implementations?

No, non è così. Sono separati

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

Il post sul blog collegato spiega che la vulnerabilità deriva dal fatto che il codice nella tabella di invio elaborazione pacchetto (in libssh \ src \ packet.c) esegue gestori per SSH2_MSG_USERAUTH_SUCCESS anche per server (anche se tale messaggio è solo dovrebbe essere elaborato dai clienti). Ulteriori indagini sul codice mostrano che l'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 proof-of-concept dettagliato 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 del blog afferma anche che:

"Not all libSSH servers will necessarily be vulnerable to the authentication bypass; since the authentication bypass sets the internal libSSH state machine to authenticated without ever giving any registered authentication callbacks an opportunity to execute, servers developed using libSSH which maintain additional custom session state may fail to function correctly if a user is authenticated without this state being created."

    
risposta data 16.10.2018 - 20:44
fonte
3

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

ldd / usr / sbin / ssh

Questo mostrerà qualsiasi dipendenza della suddetta applicazione. Quando questo comando viene eseguito, non mostra libssh che significa che libssh non fa parte di OpenSSH.

    
risposta data 17.10.2018 - 16:20
fonte

Leggi altre domande sui tag