Após três meses de desenvolvimento lançamento , uma implementação aberta de cliente e servidor para trabalhar com os protocolos SSH 2.0 e SFTP.
A nova versão inclui proteção contra ataques ao scp, permitindo que o servidor transfira outros nomes de arquivos que diferem dos solicitados (diferente da , o ataque não permite que o diretório ou máscara glob selecionados pelo usuário sejam alterados). Lembramos que no SCP, o servidor decide quais arquivos e diretórios enviar ao cliente, enquanto o cliente apenas verifica a validade dos nomes de objetos retornados. A essência do problema identificado é que, se a chamada de sistema utimes falha, o conteúdo do arquivo é interpretado como metadados do arquivo.
Esse recurso ao conectar-se a um servidor controlado por um invasor pode ser usado para salvar no sistema de arquivos do usuário outros nomes de arquivos e conteúdos diferentes ao copiar usando scp em configurações que resultem em falhas na chamada utimes (por exemplo, quando utimes é bloqueado pela política SELinux ou por um filtro de chamadas de sistema). A probabilidade de ataques reais é considerada mínima, pois em configurações típicas a chamada utimes não falha. Além disso, o ataque não passa despercebido — ao chamar scp, é exibida uma mensagem de erro de transmissão de dados.
Mudanças gerais:
- No sftp, o processamento do argumento "-1" foi interrompido de acordo com o ssh e scp, que anteriormente era aceito, mas ignorado;
- No sshd, ao usar IgnoreRhosts, agora há três opções de escolha: "yes" — ignorar rhosts/shosts, "no" — considerar rhosts/shosts e "shosts-only" — permitir " .shosts ", mas proibir " .rhosts ";
- No ssh, a substituição %TOKEN foi implementada nas configurações LocalFoward e RemoteForward, utilizadas para redirecionar soquetes Unix;
- Agora é permitido carregar chaves públicas de um arquivo não criptografado com a chave privada, se não houver um arquivo separado com a chave pública;
- Com a libcrypto disponível no sistema, o ssh e o sshd agora utilizam a implementação do algoritmo chacha20 dessa biblioteca, em vez da implementação portátil embutida, que fica atrás em termos de desempenho;
- Foi implementada a possibilidade de despejar o conteúdo da lista binária de certificados revogados ao executar o comando "ssh-keygen -lQf /path";
- Na versão portátil, foi implementada a definição de sistemas em que sinais com a opção SA_RESTART interrompem o funcionamento do select;
- Resolvemos problemas de compilação em sistemas HP/UX e AIX.
- Foram resolvidos problemas com a montagem do sandbox seccomp em algumas configurações do Linux;
- A detecção da biblioteca libfido2 foi aprimorada e problemas de montagem com a opção "--with-security-key-builtin" foram resolvidos.
Os desenvolvedores do OpenSSH também alertaram novamente sobre a iminente descontinuação dos algoritmos que utilizam hashes SHA-1, devido a da eficiência de ataques de colisão com um prefixo determinado (o custo para encontrar uma colisão é estimado em cerca de 45 mil dólares). Em uma das próximas versões, planeja-se desabilitar por padrão a possibilidade de usar o algoritmo de assinatura digital com chave pública «ssh-rsa», que é mencionado no RFC original para o protocolo SSH e continua amplamente difundido na prática (para verificar a aplicação do ssh-rsa em seus sistemas, você pode tentar se conectar via ssh com a opção «-oHostKeyAlgorithms=-ssh-rsa»).
Para suavizar a transição para novos algoritmos no OpenSSH, em uma das próximas versões, será ativada por padrão a configuração UpdateHostKeys, que permitirá transferir automaticamente os clientes para algoritmos mais seguros. Entre os algoritmos recomendados para migração estão rsa-sha2-256/512 com base no RFC8332 RSA SHA-2 (suportado desde o OpenSSH 7.2 e utilizado por padrão), ssh-ed25519 (suportado desde o OpenSSH 6.5) e ecdsa-sha2-nistp256/384/521 com base no RFC5656 ECDSA (suportado desde o OpenSSH 5.7).
A partir da versão anterior, "ssh-rsa" e "diffie-hellman-group14-sha1" foram removidos da lista CASignatureAlgorithms, que define os algoritmos permitidos para a assinatura digital de novos certificados, uma vez que o uso do SHA-1 em certificados apresenta riscos adicionais, uma vez que um atacante tem tempo ilimitado para encontrar colisões para um certificado existente, enquanto o tempo de ataque às chaves de host é limitado pelo tempo de conexão (LoginGraceTime).
Fonte: opennet.ru
