Dopo cinque mesi di sviluppo, è stato rilasciato OpenSSH 8.5, un'implementazione open source del client e del server per lavorare con i protocolli SSH 2.0 e SFTP.
Gli sviluppatori di OpenSSH hanno ricordato il prossimo passaggio degli algoritmi che utilizzano gli hash SHA-1 nella categoria degli algoritmi obsoleti, a causa dell'aumento dell'efficacia degli attacchi di collisione con prefisso predeterminato (il costo per generare una collisione è stimato attorno ai 50.000 dollari). In uno dei prossimi rilasci, intendono disattivare di default l'uso dell'algoritmo di firma digitale con chiave pubblica «ssh-rsa», che è menzionato nell'RFC originale per il protocollo SSH e rimane ampiamente utilizzato nella pratica.
Per verificare l'uso di ssh-rsa nei propri sistemi, è possibile provare a connettersi via ssh con l'opzione «-oHostKeyAlgorithms=-ssh-rsa». Tuttavia, la disattivazione per impostazione predefinita delle firme digitali «ssh-rsa» non implica un rifiuto totale dell'uso delle chiavi RSA, poiché, oltre a SHA-1, il protocollo SSH consente di utilizzare altri algoritmi di hashing. In particolare, oltre a «ssh-rsa», rimarrà la possibilità di utilizzare le coppie «rsa-sha2-256» (RSA/SHA256) e «rsa-sha2-512» (RSA/SHA512).
Per facilitare la transizione verso i nuovi algoritmi in OpenSSH 8.5, la configurazione UpdateHostKeys è abilitata per impostazione predefinita, consentendo il passaggio automatico dei client a algoritmi più sicuri. Con questa configurazione viene attivata un'estensione speciale del protocollo "hostkeys@openssh.com", che permette al server, dopo l'autenticazione, di informare il client su tutte le chiavi host disponibili. Il client può riflettere queste chiavi nel suo file ~/.ssh/known_hosts, organizzando così l'aggiornamento delle chiavi host e semplificando la sostituzione delle chiavi su server.
L'uso di UpdateHostKeys è soggetto a alcune condizioni che potrebbero essere revocate in futuro: la chiave deve essere presente in UserKnownHostsFile e non deve essere utilizzata in GlobalKnownHostsFile; la chiave deve avere un solo nome; non deve essere utilizzato un certificato della chiave host; non devono essere usate maschere per il nome host in known_hosts; la configurazione VerifyHostKeyDNS deve essere disabilitata; il parametro UserKnownHostsFile deve essere abilitato.
Tra gli algoritmi raccomandati per la migrazione sono menzionati rsa-sha2-256/512 basati su RFC8332 RSA SHA-2 (supportato da OpenSSH 7.2 e utilizzato per impostazione predefinita), ssh-ed25519 (supportato da OpenSSH 6.5) ed ecdsa-sha2-nistp256/384/521 basati su RFC5656 ECDSA (supportato da OpenSSH 5.7).
Altre modifiche:
- Modifiche relative alla sicurezza:
- Nel ssh-agent è stata risolta una vulnerabilità causata dal doppio rilascio di memoria già liberata (double-free). Il problema si presenta con il rilascio di OpenSSH 8.2 e può essere potenzialmente sfruttato se l'attaccante ha accesso al socket ssh-agent sulla sistema locale. L'esploitàzione è complicata dal fatto che l'accesso al socket è riservato solo a root e all'utente originale. Lo scenario di attacco più probabile prevede un reindirizzamento dell'agente a un account sotto il controllo dell'attaccante o a un host sul quale l'attaccante ha accesso root.
- In sshd è stata aggiunta una protezione contro la trasmissione di parametri molto grandi con il nome utente nel sottosistema PAM, che consente di bloccare vulnerabilità nei moduli PAM (Pluggable Authentication Module). Ad esempio, questa modifica aiuta a prevenire l'uso di sshd come vettore per sfruttare la vulnerabilità root recentemente scoperta in Solaris (CVE-2020-14871).
- Modifiche che potrebbero compromettere la compatibilità:
- In ssh e sshd è stato riprogettato un metodo sperimentale di scambio di chiavi resistente agli attacchi da parte di computer quantistici. I computer quantistici risolvono drasticamente più rapidamente il problema della scomposizione dei numeri naturali in fattori primi, fondamentale per gli attuali algoritmi di crittografia asimmetrica, che non possono essere risolti in modo efficiente su processori classici. Il metodo utilizzato si basa sull'algoritmo NTRU Prime, sviluppato per i sistemi crittografici post-quantum, e su un metodo di scambio di chiavi basato su curve ellittiche X25519. Invece di sntrup4591761x25519-sha512@tinyssh.org, il metodo è ora identificato come sntrup761x25519-sha512@openssh.com (l'algoritmo sntrup4591761 è stato sostituito con sntrup761).
- In ssh and sshd, the order of announcement for supported digital signature algorithms has changed. ED25519 is now prioritized over ECDSA.
- In ssh and sshd, the setting of TOS/DSCP quality parameters for interactive sessions is now done before establishing the TCP connection.
- In ssh and sshd, support for the rijndael-cbc@lysator.liu.se cipher has been removed, which is identical to aes256-cbc and was used before RFC-4253 was adopted.
- By default, the CheckHostIP option is disabled, which offers minimal benefits but significantly complicates key rotation for hosts behind load balancers.
- In sshd, new settings PerSourceMaxStartups and PerSourceNetBlockSize have been added to limit the intensity of handler startups based on the client's address. These parameters allow more precise control over process startup limits compared to the general MaxStartups setting.
- In ssh and sshd, a new LogVerbose setting has been introduced, enabling forced increases in the level of debug information logged, with filtering options available by patterns, functions, and files.
- In ssh, when accepting a new host key, all host names and IP addresses, associati alla chiave.
- In ssh è possibile specificare l'opzione UserKnownHostsFile=none per disabilitare l'uso del file known_hosts durante l'identificazione delle chiavi host.
- Nel ssh_config per ssh è stata aggiunta l'impostazione KnownHostsCommand, che consente di ottenere i dati di known_hosts dall'output di un comando specificato.
- Nel ssh_config per ssh è stata aggiunta l'opzione PermitRemoteOpen, che limita il punto di destinazione quando si utilizza l'opzione RemoteForward con SOCKS.
- In ssh, per le chiavi FIDO è garantita una nuova richiesta di PIN in caso di errore nell'operazione di firma digitale a causa di un PIN errato, senza che l'utente possa richiederne uno (ad esempio, quando non sono stati acquisiti dati biometrici corretti e il dispositivo è tornato all'immissione manuale del PIN).
- Nell'sshd, al meccanismo di isolamento del processo basato su seccomp-bpf sulla piattaforma Linux è stata aggiunta la supporto per ulteriori chiamate di sistema.
- Aggiornato lo strumento contrib/ssh-copy-id.
Fonte: opennet.ru
