Rilascio di OpenSSH 8.9 con eliminazione della vulnerabilità in sshd

Dopo sei mesi di sviluppo è stata presentata la release OpenSSH 8.9, un'implementazione client e server aperta per lavorare sui protocolli SSH 2.0 e SFTP. La nuova versione di sshd risolve una vulnerabilità che potrebbe potenzialmente consentire l'accesso non autenticato. Il problema è causato da un overflow di numeri interi nel codice di autenticazione, ma può essere sfruttato solo in combinazione con altri errori logici nel codice.

Nella sua forma attuale, la vulnerabilità non può essere sfruttata quando è abilitata la modalità di separazione dei privilegi, poiché la sua manifestazione è bloccata da controlli separati eseguiti nel codice di tracciamento della separazione dei privilegi. La modalità di separazione dei privilegi è stata abilitata per impostazione predefinita dal 2002 a partire da OpenSSH 3.2.2 ed è obbligatoria dal rilascio di OpenSSH 7.5 pubblicato nel 2017. Inoltre, nelle versioni portatili di OpenSSH a partire dalla versione 6.5 (2014), la vulnerabilità viene bloccata tramite compilazione con l'inclusione di flag di protezione da overflow di numeri interi.

Altre modifiche:

  • La versione portatile di OpenSSH in sshd ha rimosso il supporto nativo per l'hashing delle password utilizzando l'algoritmo MD5 (permettendo il collegamento con librerie esterne come libxcrypt).
  • ssh, sshd, ssh-add e ssh-agent implementano un sottosistema per limitare l'inoltro e l'uso delle chiavi aggiunte a ssh-agent. Il sottosistema consente di impostare regole che determinano come e dove le chiavi possono essere utilizzate in ssh-agent. Ad esempio, per aggiungere una chiave che può essere utilizzata solo per autenticare qualsiasi utente che si connette all'host scylla.example.org, l'utente perseus all'host cetus.example.org e l'utente medea all'host charybdis.example.org con il reindirizzamento tramite un host intermedio scylla.example.org, puoi utilizzare il seguente comando: $ ssh-add -h "[email protected]» \ -h «scylla.example.org» \ -h «scylla.example.org>[email protected]» \ ~/.ssh/id_ed25519
  • In ssh e sshd, per impostazione predefinita è stato aggiunto un algoritmo ibrido all'elenco KexAlgorithms, che determina l'ordine in cui vengono selezionati i metodi di scambio delle chiavi.[email protected]"(ECDH/x25519 + NTRU Prime), resistente alla selezione sui computer quantistici. In OpenSSH 8.9, questo metodo di negoziazione è stato aggiunto tra i metodi ECDH e DH, ma si prevede che sarà abilitato per impostazione predefinita nella prossima versione.
  • ssh-keygen, ssh e ssh-agent hanno migliorato la gestione delle chiavi token FIDO utilizzate per la verifica del dispositivo, incluse le chiavi per l'autenticazione biometrica.
  • Aggiunto il comando "ssh-keygen -Y match-principals" a ssh-keygen per controllare i nomi utente nel file consentitinamelist.
  • ssh-add e ssh-agent forniscono la possibilità di aggiungere chiavi FIDO protette da un codice PIN a ssh-agent (la richiesta del PIN viene visualizzata al momento dell'autenticazione).
  • ssh-keygen consente la scelta dell'algoritmo di hashing (sha512 o sha256) durante la generazione della firma.
  • In ssh e sshd, per migliorare le prestazioni, i dati di rete vengono letti direttamente nel buffer dei pacchetti in entrata, bypassando il buffering intermedio sullo stack. Il posizionamento diretto dei dati ricevuti in un buffer di canale viene implementato in modo simile.
  • In ssh, la direttiva PubkeyAuthentication ha ampliato l'elenco dei parametri supportati (yes|no|unbound|host-bound) per fornire la possibilità di selezionare l'estensione del protocollo da utilizzare.

In una versione futura, prevediamo di modificare l'impostazione predefinita dell'utilità scp per utilizzare SFTP anziché il protocollo SCP/RCP legacy. SFTP utilizza metodi di gestione dei nomi più prevedibili e non utilizza l'elaborazione della shell dei modelli glob nei nomi dei file sul lato dell'altro host, il che crea problemi di sicurezza. In particolare, quando si utilizzano SCP e RCP, il server decide quali file e directory inviare al client, e il client si limita a verificare la correttezza dei nomi degli oggetti restituiti, il che, in assenza di adeguati controlli lato client, consente la server per trasferire altri nomi di file diversi da quelli richiesti. Il protocollo SFTP non presenta questi problemi, ma non supporta l'espansione di percorsi speciali come “~/”. Per risolvere questa differenza, la versione precedente di OpenSSH ha introdotto una nuova estensione del protocollo SFTP ai percorsi ~/ e ~user/ nell'implementazione del server SFTP.

Fonte: opennet.ru

Aggiungi un commento