Dopo cinque mesi di sviluppo viene presentata la versione OpenSSH 8.5, un'implementazione aperta di client e server per lavorare sui protocolli SSH 2.0 e SFTP.
Gli sviluppatori di OpenSSH ci hanno ricordato l'imminente smantellamento degli algoritmi che utilizzano hash SHA-1 a causa della maggiore efficienza degli attacchi di collisione con un determinato prefisso (il costo per la selezione di una collisione è stimato in circa 50mila dollari). In una delle prossime versioni, si prevede di disabilitare per impostazione predefinita la possibilità di utilizzare l'algoritmo di firma digitale a chiave pubblica "ssh-rsa", menzionato nell'RFC originale per il protocollo SSH e rimane ampiamente diffuso nella pratica.
Per testare l'utilizzo di ssh-rsa sui vostri sistemi, potete provare a connettervi via ssh con l'opzione “-oHostKeyAlgorithms=-ssh-rsa”. Allo stesso tempo, disabilitare per impostazione predefinita le firme digitali “ssh-rsa” non significa un completo abbandono dell’uso delle chiavi RSA, poiché oltre a SHA-1, il protocollo SSH consente l’utilizzo di altri algoritmi di calcolo dell’hash. In particolare, oltre a “ssh-rsa”, resterà possibile utilizzare i bundle “rsa-sha2-256” (RSA/SHA256) e “rsa-sha2-512” (RSA/SHA512).
Per agevolare la transizione ai nuovi algoritmi, OpenSSH 8.5 ha l'impostazione UpdateHostKeys abilitata per impostazione predefinita, che consente ai client di passare automaticamente ad algoritmi più affidabili. Utilizzando questa impostazione, viene abilitata una speciale estensione del protocollo “[email protected]", consentendo 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, che consente l'aggiornamento delle chiavi host e semplifica la modifica delle chiavi sul server.
L'uso di UpdateHostKeys è limitato da diversi avvertimenti che potrebbero essere rimossi in futuro: la chiave deve essere referenziata in UserKnownHostsFile e non utilizzata in GlobalKnownHostsFile; la chiave deve essere presente sotto un solo nome; non deve essere utilizzato un certificato di chiave host; inknown_hosts le maschere in base al nome host non dovrebbero essere utilizzate; l'impostazione VerifyHostKeyDNS deve essere disabilitata; Il parametro UserKnownHostsFile deve essere attivo.
Gli algoritmi consigliati per la migrazione includono rsa-sha2-256/512 basato su RFC8332 RSA SHA-2 (supportato da OpenSSH 7.2 e utilizzato per impostazione predefinita), ssh-ed25519 (supportato da OpenSSH 6.5) e basato su ecdsa-sha2-nistp256/384/521 su RFC5656 ECDSA (supportato da OpenSSH 5.7).
Altre modifiche:
- Modifiche alla sicurezza:
- Una vulnerabilità causata dalla riliberazione di un'area di memoria già liberata (double-free) è stata risolta in ssh-agent. Il problema è presente sin dal rilascio di OpenSSH 8.2 e può essere potenzialmente sfruttato se un utente malintenzionato ha accesso al socket ssh-agent sul sistema locale. Ciò che rende lo sfruttamento più difficile è che solo root e l'utente originale hanno accesso al socket. Lo scenario di attacco più probabile è che l'agente venga reindirizzato a un account controllato dall'aggressore o a un host in cui l'aggressore ha accesso root.
- sshd ha aggiunto la protezione contro il passaggio di parametri molto grandi con il nome utente al sottosistema PAM, che consente di bloccare le vulnerabilità nei moduli di sistema PAM (Pluggable Authentication Module). Ad esempio, la modifica impedisce che sshd venga utilizzato come vettore per sfruttare una vulnerabilità root scoperta di recente in Solaris (CVE-2020-14871).
- Modifiche alla compatibilità potenzialmente dannose:
- В ssh и sshd переработан экспериментальный метод обмена ключами, стойкий к подбору на квантовом компьютере. Квантовые компьютеры кардинально быстрее решают задачу разложения натурального числа на простые множители, которая лежит в основе современных асимметричных алгоритмов шифрования и эффективно не решаема на классических процессорах. Используемый метод основан на алгоритме NTRU Prime, разработанном для постквантумных криптосистем, и методе обмена ключами на базе эллиптических кривых X25519. Вместо [email protected] метод теперь идентифицируется как [email protected] (l'algoritmo sntrup4591761 è stato sostituito da sntrup761).
- In ssh e sshd è stato modificato l'ordine in cui vengono annunciati gli algoritmi di firma digitale supportati. ED25519 viene ora offerto per primo al posto dell'ECDSA.
- In ssh e sshd, l'impostazione dei parametri di qualità del servizio TOS/DSCP per le sessioni interattive viene ora eseguita prima di stabilire una connessione TCP.
- Il supporto della crittografia è stato interrotto in ssh e sshd [email protected], che è identico a aes256-cbc ed è stato utilizzato prima dell'approvazione di RFC-4253.
- Per impostazione predefinita, il parametro CheckHostIP è disabilitato, il cui vantaggio è trascurabile, ma il suo utilizzo complica notevolmente la rotazione delle chiavi per gli host dietro i bilanciatori del carico.
- Le impostazioni PerSourceMaxStartups e PerSourceNetBlockSize sono state aggiunte a sshd per limitare l'intensità dell'avvio dei gestori in base all'indirizzo del client. Questi parametri consentono di controllare in modo più preciso il limite sugli avvii dei processi, rispetto all'impostazione generale di MaxStartups.
- Una nuova impostazione LogVerbose è stata aggiunta a ssh e sshd, che consente di aumentare forzatamente il livello delle informazioni di debug inserite nel registro, con la possibilità di filtrare per modelli, funzioni e file.
- In ssh, quando si accetta una nuova chiave host, vengono visualizzati tutti i nomi host e gli indirizzi IP associati alla chiave.
- ssh consente all'opzione UserKnownHostsFile=none di disabilitare l'uso del fileknown_hosts durante l'identificazione delle chiavi host.
- Un'impostazione KnownHostsCommand è stata aggiunta a ssh_config per ssh, consentendoti di ottenere datiknown_hosts dall'output del comando specificato.
- Aggiunta un'opzione PermitRemoteOpen a ssh_config per ssh per consentire di limitare la destinazione quando si utilizza l'opzione RemoteForward con SOCKS.
- In ssh per le chiavi FIDO è prevista una richiesta ripetuta del PIN nel caso in cui l'operazione di firma digitale fallisca a causa di un PIN errato e non venga richiesto all'utente il PIN (ad esempio, quando non è possibile ottenere i dati biometrici corretti e dispositivo è tornato all'immissione manuale del PIN).
- sshd aggiunge il supporto per ulteriori chiamate di sistema al meccanismo di isolamento dei processi basato su seccomp-bpf su Linux.
- L'utilità contrib/ssh-copy-id è stata aggiornata.
Fonte: opennet.ru