Dopo sei mesi di sviluppo, è stato presentato il rilascio di OpenSSH 8.9, un'implementazione open source di client e server per il protocollo SSH 2.0 e SFTP. Nella nuova versione è stata corretta una vulnerabilità in sshd che potenzialmente permetteva l'accesso senza autenticazione. Il problema è causato da un overflow intero nel codice di autenticazione, ma l'esploitazione è possibile solo in combinazione con altri errori logici nel codice.
Nella sua forma attuale, la vulnerabilità non è sfruttabile con l'attivazione della modalità di separazione dei privilegi, poiché la sua manifestazione è bloccata da controlli specifici eseguiti nel codice di monitoraggio della separazione dei privilegi. La modalità di separazione dei privilegi è attivata di default dal 2002, a partire da OpenSSH 3.2.2, ed è obbligatoria a partire dal rilascio di OpenSSH 7.5, pubblicato nel 2017. Inoltre, nelle versioni portabili di OpenSSH a partire dalla versione 6.5 (2014), la vulnerabilità è bloccata dalla compilazione con l'attivazione dei flag di protezione contro gli overflow interi.
Altre modifiche:
- Nella versione portabile di OpenSSH, è stata rimossa la supporto integrato per l'hashing delle password utilizzando l'algoritmo MD5 (è consentito il collegamento a librerie esterne, come libxcrypt).
- In ssh, sshd, ssh-add e ssh-agent è stata implementata una sottosistema per limitare il forwarding e l'uso delle chiavi aggiunte in ssh-agent. La sottosistema permette di definire regole che determinano come e dove è possibile utilizzare le chiavi in ssh-agent. Ad esempio, per aggiungere una chiave che può essere usata solo per l'autenticazione durante il collegamento di qualsiasi utente all'host scylla.example.org, l'utente perseus all'host cetus.example.org e l'utente medea all'host charybdis.example.org tramite un host intermedio scylla.example.org, si può utilizzare il seguente comando: $ ssh-add -h "perseus@cetus.example.org" \ -h "scylla.example.org" \ -h "scylla.example.org>medea@charybdis.example.org" \ ~/.ssh/id_ed25519
- In ssh e sshd, è stato aggiunto di default l'algoritmo ibrido "sntrup761x25519-sha512@openssh.com" (ECDH/x25519 + NTRU Prime) alla lista KexAlgorithms, che definisce l'ordine di selezione dei metodi di scambio delle chiavi. Nella versione OpenSSH 8.9, questo metodo di accordo è stato aggiunto tra i metodi ECDH e DH, ma nel prossimo rilascio si prevede che venga utilizzato di default.
- In ssh-keygen, ssh e ssh-agent è stata migliorata la gestione delle chiavi dei token FIDO utilizzati per la verifica del dispositivo, comprese le chiavi per l'autenticazione biometrica.
- In ssh-keygen è stato aggiunto il comando «ssh-keygen -Y match-principals» per verificare i nomi utente nel file con l'elenco dei nomi autorizzati.
- In ssh-add e ssh-agent è stata fornita la possibilità di aggiungere chiavi FIDO protette da PIN nell'ssh-agent (la richiesta del PIN viene visualizzata al momento dell'autenticazione).
- In ssh-keygen è stata consentita la scelta dell'algoritmo di hashing (sha512 o sha256) durante la generazione della firma.
- In ssh e sshd, per migliorare le prestazioni, è stato implementato il caricamento diretto dei dati di rete nel buffer dei pacchetti in entrata, bypassando il buffering intermedio nello stack. Analogamente, è stato realizzato il posizionamento diretto dei dati ricevuti nel buffer del canale.
- In ssh, nella direttiva PubkeyAuthentication, è stata ampliata l'elenco dei parametri supportati (yes|no|unbound|host-bound) per fornire la possibilità di scegliere l'opzione di estensione del protocollo utilizzato.
In uno dei prossimi rilasci, si prevede di passare per impostazione predefinita l'utilità scp all'uso di SFTP invece del protocollo obsoleto SCP/RCP. In SFTP vengono utilizzati metodi di gestione dei nomi più prevedibili e non viene effettuata la gestione dei modelli glob nei nomi dei file tramite shell sul lato di un altro host, che crea problemi di sicurezza. In particolare, quando si utilizza SCP e RCP, il server decide quali file e cartelle inviare al client, mentre il client controlla solo la correttezza dei nomi degli oggetti restituiti, il che, in assenza di controlli adeguati da parte del client, consente server di trasferire nomi di file diversi da quelli richiesti. Il protocollo SFTP è esente dai problemi menzionati, ma non supporta la rivelazione dei percorsi speciali, come «~/». Per eliminare questa differenza, in una versione precedente di OpenSSH è stata proposta una nuova estensione del protocollo SFTP per la rivelazione dei percorsi ~/ e ~user/.
Fonte: opennet.ru
