Dopo tre mesi di sviluppo rilasciare , un'implementazione client e server aperta per lavorare tramite i protocolli SSH 2.0 e SFTP.
La nuova versione aggiunge protezione contro un attacco a scp che consente al server di passare nomi di file diversi da quelli richiesti (a differenza , l'attacco non consente di modificare la directory selezionata dall'utente o la maschera glob. Ricordiamo che in SCP è il server a decidere quali file e directory inviare al client, e il client controlla solo la correttezza dei nomi degli oggetti restituiti. L'essenza del problema identificato è che se la chiamata di sistema utimes fallisce, il contenuto del file viene interpretato come metadati del file.
Questa funzionalità, quando ci si connette a un server controllato da un attaccante, può essere utilizzata per salvare altri nomi di file e altri contenuti nel file system dell'utente durante la copia tramite scp in configurazioni che portano a un errore durante la chiamata di utimes (ad esempio, quando utimes sono proibiti dalla policy SE).Linux (o un filtro per le chiamate di sistema). Si stima che la probabilità di attacchi reali sia minima, poiché nelle configurazioni tipiche la chiamata utimes non fallisce. Inoltre, l'attacco non è silenzioso: viene segnalato un errore di trasferimento dati durante la chiamata a scp.
Modifiche generali:
- sftp non gestisce più l'argomento "-1", simile a ssh e scp, che in precedenza era accettato ma ignorato;
- In sshd, quando si utilizza IgnoreRhosts, ora vengono fornite tre opzioni: "yes" - ignora rhosts/shosts, "no" - rispetta rhosts/shosts e "shosts-only" - consente ".shosts" ma non ".rhosts";
- ssh ora gestisce la sostituzione %TOKEN nelle impostazioni LocalFoward e RemoteForward utilizzate per l'inoltro dei socket Unix;
- Consentire il caricamento delle chiavi pubbliche da un file di chiavi private non crittografate se non è presente un file di chiavi pubbliche separato;
- Se libcrypto è presente nel sistema, ssh e sshd ora utilizzano l'implementazione dell'algoritmo chacha20 di questa libreria, anziché l'implementazione portatile integrata, che presenta prestazioni inferiori;
- Implementata la possibilità di scaricare il contenuto dell'elenco binario dei certificati revocati durante l'esecuzione del comando "ssh-keygen -lQf /path";
- La versione portatile implementa le definizioni dei sistemi in cui i segnali con l'opzione SA_RESTART interrompono l'operazione di selezione;
- Risolti problemi di compilazione sui sistemi HP/UX e AIX;
- Risolti alcuni problemi con le build della sandbox seccomp in alcune configurazioni Linux;
- Migliorato il rilevamento della libreria libfido2 e risolti i problemi con la compilazione con l'opzione "--with-security-key-builtin".
Gli sviluppatori di OpenSSH hanno nuovamente avvertito della prossima deprecazione degli algoritmi che utilizzano hash SHA-1, a causa di l'efficacia degli attacchi di collisione con un determinato prefisso (il costo per la selezione di una collisione è stimato in circa 45mila 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”, che è menzionato nell'RFC originale per il protocollo SSH e rimane diffuso nella pratica (per testare l'uso di ssh-rsa nei vostri sistemi, potete provare a connettervi via ssh con l'opzione “-oHostKeyAlgorithms=-ssh-rsa”).
Per facilitare la transizione ai nuovi algoritmi in OpenSSH, in una versione futura l'impostazione UpdateHostKeys sarà abilitata per impostazione predefinita, che migrerà automaticamente i client ad algoritmi più affidabili. 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).
Dalla versione precedente, "ssh-rsa" e "diffie-hellman-group14-sha1" sono stati rimossi dall'elenco CASignatureAlgorithms che definisce gli algoritmi autorizzati a firmare digitalmente nuovi certificati, poiché l'utilizzo di SHA-1 nei certificati comporta il rischio aggiuntivo che un aggressore abbia tempo illimitato per trovare una collisione per un certificato esistente, mentre il tempo di attacco per le chiavi host è limitato dal timeout della connessione (LoginGraceTime).
Fonte: opennet.ru
