NBSO - NIC BR Security Office
CGI.br - Comitê Gestor da Internet no Brasil
Chave PGP: http://www.nbso.nic.br/pgp/nbso@nic.br.asc

Tradução dos Advisories do CERT/CC, com permissão especial do Software Engineering Institute (SEI).

CERT^® Advisory CA-2002-18 Vulnerabilidades no "Challenge Response" do OpenSSH

Data original de lançamento: 26 de junho de 2002
Última Revisão: --
Origem: CERT/CC

Um histórico completo das revisões pode ser encontrado ao final deste documento.

Sistemas Afetados

• OpenSSH versões 2.3.1p1 a 3.3

Resumo

Existem duas vulnerabilidades correlacionadas no código de manipulação do "challenge response" nas versões 2.3.1p1 a 3.3 do OpenSSH. Elas podem permitir a um atacante remoto a execução de códigos arbitrários com os privilégios do usuário executando o sshd (root, freqüentemente). A primeira vulnerabilidade afeta as versões 2.9.9 a 3.3 do OpenSSH que possuem a opção de "challenge response" habilitada e que utilizam as autenticações SKEY ou BSD_AUTH. A segunda vulnerabilidade afeta módulos PAM que utilizam autenticação interativa via teclado nas versões 2.3.1p1 a 3.3 do OpenSSH, independente do ajuste da opção do "challenge response". Adicionalmente, outros possíveis problemas de segurança foram corrigidos na versão 3.4 do OpenSSH.

I. Descrição

Duas vulnerabilidades correlacionadas foram encontradas na manipulação das "challenge responses" no OpenSSH.

A primeira vulnerabilidade é um overflow de inteiro na manipulação do número de respostas recebidas durante a autenticação por "challenge response". Se a opção de configuração do "challenge response" é ajustada para "yes" e o sistema está utilizando autenticação SKEY ou BSD_AUTH então um atacante remoto poderá explorar a vulnerabilidade para executar um código arbitrário. Esta vulnerabilidade está presente nas versões 2.9.9 a 3.3 do OpenSSH. Sabe-se da existência de um exploit para esta vulnerabilidade. Esta vulnerabilidade está parcialmente descrita em um advisory de segurança da ISS disponível em:

http://bvlive01.iss.net/issEn/delivery/xforce/alertdetail.jsp?oid=20584

A segunda vulnerabilidade é um buffer overflow envolvendo o número de respostas recebidas durante a autenticação por "challenge response". Os sistemas que utilizam os módulos PAM com autenticação interativa por teclado (PAMAuthenticationViaKbdInt), independente da opção de configuração do "challenge response", podem ser vulneráveis à execução remota de código. Até o momento, não se sabe se esta vulnerabilidade pode ser explorada. Correções para ambas as vulnerabilidades podem ser encontradas no advisory de segurança do OpenSSH disponível em:

http://www.openssh.com/txt/preauth.adv

Ambas as vulnerabilidades exploram características que estão presentes somente na versão 2 do protocolo SSH.

A "Vulnerabilility Note VU#369347" lista os fornecedores que foram contactados a respeito destas vulnerabilidades. Este documento está disponível em:

http://www.kb.cert.org/vuls/id/369347

II. Impacto

Um atacante remoto pode executar códigos com privilégios do usuário que está executando o sshd (root, freqüentemente). Estas vulnerabilidades também podem ser utilizadas para causar uma condição de negação de serviço.

III. Solução

Atualizar o OpenSSH para a versão 3.4

Estas vulnerabilidades são eliminadas através da atualização para o OpenSSH versão 3.4, que está disponível na página do OpenSSH em:

http://www.openssh.com

A versão 3.4 do OpenSSH corrige outros defeitos de software, com possíveis implicações de segurança não descritas neste advisory.

Aplicar a correção disponibilizada pelo seu fornecedor

Uma correção para este problema está incluída no advisory do OpenSSH em:

http://www.openssh.com/txt/preauth.adv

Esta correção pode ser instalada manualmente, com pequenas alterações, para corrigir estas vulnerabilidades em todas as versões afetadas do OpenSSH. Note que aplicar as correções descritas no advisory do OpenSSH não corrige outros defeitos do software, com possíveis implicações de segurança que não foram descritas neste advisory.

Caso o seu fornecedor tenha disponibilizado uma correção para estas vulnerabilidades, você pode escolher utilizá-la em substituição à atualização de sua versão de sshd. Administradores de sistemas podem sentir necessidade de confirmar com os fornecedores se as correções fornecidas eliminam as outras possíveis vulnerabilidades corrigidas na versão 3.4 do OpenSSH. Mais informações sobre as correções específicas de cada fornecedor podem ser encontradas na seção de fornecedores deste documento. Como a publicação deste advisory foi inadvertidamente acelerada, os comentários de todos os fornecedores não estavam disponíveis até o momento da publicação deste documento. À medida que informações adicionais sejam providas pelos fornecedores, este documento será atualizado.

Desabilitar a versão 2 do protocolo SSH

Como ambas as vulnerabilidades estão presentes somente nas funcionalidades da versão 2 do protocolo, desabilitar a versão 2 do protocolo prevenirá a exploração destas vulnerabilidades. Normalmente, isto é realizado adicionando-se a seguinte linha ao arquivo /etc/ssh/sshd_config:

     Protocol 1

Esta opção pode estar ajustada para "2,1" na configuração padrão. Administradores de sistemas devem estar atentos que, ao desabilitar a versão 2 do protocolo, poderão impedir o "daemon sshd" de aceitar conexões em determinadas configurações. A utilização de uma ou ambas as alterações de configuração descritas abaixo pode ser uma solução provisória com menor impacto no sistema.

Desabilitar a autenticação por "challenge response"

Para as versões do OpenSSH maiores que 2.9, os administradores de sistemas podem desabilitar a porção vulnerável do código ajustando a opção de configuração "ChallengeResponseAuthentication" para "no" no arquivo de configuração do sshd. Normalmente, isto é realizado pela adição da seguinte linha ao arquivo /etc/ssh/sshd_config:

     ChallengeResponseAuthentication no

Esta opção pode estar habilitada (com o valor "yes") na configuração padrão. Esta solução provisória deve prevenir a exploração da primeira vulnerabilidade, se a autenticação SKEY ou BSD_AUTH for utilizada. Isto não impede uma possível exploração da vulnerabilidade via módulo PAM de autenticação interativa pelo teclado.

Desabilitar a autenticação PAM interativa via teclado

Para as versões do OpenSSH maiores que 2.9, os administradores de sistemas podem desabilitar a porção vulnerável do código, que afeta a autenticação PAM, ajustando a opção de configuração "PAMAuthenticationViaKbdInt" para "no" no arquivo de configuração do sshd. Normalmente, isto é realizado adicionando-se a seguinte linha ao arquivo /etc/ssh/sshd_config:

     PAMAuthenticationViaKbdInt no

Esta opção pode estar desabilitada (com o valor "no") na configuração padrão. Esta solução provisória prevenirá a exploração da segunda vulnerabilidade, se o módulo PAM de autenticação interativa via teclado for utilizado. Isto não prevenirá a exploração da vulnerabilidade via autenticação SKEY ou BSD_AUTH.

Desabilitar ambas as opções nas versões antigas do OpenSSH

Para as versões do OpenSSH entre 2.3.1p1 e 2.9, os administradores de sistemas precisam configurar as seguintes opções no arquivo de configuração do ssh:

     KbdInteractiveAuthentication no
     ChallengeResponseAuthentication no

Acredita-se que a desabilitação destas duas opções evita a exploração das vulnerabilidades, independentemente do mecanismo de autenticação utilizado.

Usar a separação de privilégios para minimizar o impacto

Administradores de sistemas utilizando as versões 3.2 ou 3.3 do OpenSSH podem reduzir o impacto destas vulnerabilidades habilitando a opção de configuração "UsePrivilegeSeparation" no arquivo de configuração do sshd. Normalmente, isto é realizado adicionando-se a seguinte linha ao arquivo /etc/ssh/sshd_config:

     UsePrivilegeSeparation yes

Esta solução não previne a exploração destas vulnerabilidades, entretanto, devido ao mecanismo de separação de privilégios, o atacante será limitado a um ambiente chroot com privilégios restritos. Esta solução não impedirá que estas vulnerabilidades criem uma condição de negação de serviço. Nem todos os fornecedores de sistemas operacionais implementam o código de separação de privilégios e, em determinados sistemas operacionais, isto pode limitar a funcionalidade do OpenSSH. Os administradores de sistemas são encorajados a rever cuidadosamente as implicações da utilização desta solução em seus ambientes e a utilizar uma solução mais abrangente, caso seja possível. Encoraja-se o uso da separação de privilégios para limitar o impacto de vulnerabilidades futuras.

Apêndice A. - Informações dos Fornecedores

Este apêndice contém informações providas pelos próprios fornecedores para inclusão neste documento. À medida que os fornecedores enviarem novas informações ao CERT/CC, este documento será atualizado e as modificações serão registradas no histórico de revisões. Se algum fornecedor em particular não estiver listado abaixo é porque não recebemos seus comentários.

Compaq Computer Corporation

ORIGEM: Compaq Computer Corporation, uma subsidiária da Hewlett-Packard Company e da Hewlett-Packard Company HP Services. Software Security Response Team

x-ref:SSRT2263

Até o momento da redação deste documento, a Compaq encontra-se investigando o impacto potencial no HP Tru64 UNIX, versão comercial do SSH para V5.1a.

Na medida em que mais informações estiverem disponíveis, serão fornecidas notificações sobre a finalização/disponibilidade de quaisquer correções necessárias, através dos anúncios do "product and security bulletin" e através dos canais normais de suporte do HP Services.

Caldera

O Caldera OpenLinux OpenSSH não possui as funcionalidades S/KEY ou BSD Auth compiladas internamente, assim sendo ele não é suscetível à vulnerabilidade Challenge/Response. Entretanto, nós temos a opção ChallengeResponseAuthentication habilitada na configuração padrão, de modo que, por questões de segurança, recomendamos que a opção seja desabilitada no arquivo sshd_config.

Adicionalmente, a opção de configuração PAMAuthenticationViaKbdInt é desabilitada na configuração padrão, de modo que o OpenLinux também não é suscetível à outra vulnerabilidade apontada na configuração padrão. Entretanto, a Caldera recomenda que esta opção seja desabilitada caso tenha sido habilitada pelo administrador de sistemas.

Cray, Inc.

A Cray, Inc. constatou que o OpenSSH distribuído no Cray Open Software 3.0 é vulnerável. Por favor, verifiquem o "Field Notice 5105" e o "spr 722588" para informações sobre as correções.

Debian

O Debian 2.2 (versão estável corrente) não é afetado por estes problemas. As versões correntes de nossa distribuição de "testes", que se tornará o Debian 3.0, e de nossa distribuição "instável" são ambas afetadas na configuração padrão.

Nós recomendamos que os usuários se certifiquem que as opções:

ChallengeResponseAuthentication no

e

PAMAuthenticationViaKbdInt no

estejam presentes e descomentadas no arquivo /etc/ssh/sshd_config (e que o servidor seja reinicializado). Recomendamos, também, o uso da versão 3.3p1, disponível agora em security.debian.org (DSA-134). Usuários da versão estável não necessitam realizar a atualização e podem esperar até que os pacotes tenham recebido testes melhores.

Pretendemos disponibilizar os pacotes da versão 3.4p1 em um futuro próximo.

Engarde

A Guardian Digital distribui o OpenSSH em todas as versões do EnGarde Secure Linux. A versão 3.3p1 foi introduzida pelo ESA-20020625-015 no dia 25 de junho de 2002. Esta atualização introduz a separação de privilégios. Todos os usuários são fortemente encorajados a atualizar para esta versão o mais rápido possível.

A atualização para a versão 3.4p1 (que corrige estes problemas) estará disponível nos próximos dias.

Hewlett-Packard Company

A Hewlett-Packard possui uma versão do SSH: HP-UX Secure Shell (T1471AA) para as versões 11.00 e 11i do HP-UX. Estamos investigando para determinar se este produto é vulnerável.

IBM Corporation

O sistema operacional AIX da IBM não é distribuído com o OpenSSH; entretanto, o OpenSSH está disponível para instalação no AIX via Linux Affinity Toolkit. A versão incluída no CD contendo o Toolkit é suscetível à última vulnerabilidade descoberta discutida aqui, bem como a versão do OpenSSH disponível para download no website do IBM Linux Affinity. Qualquer um executando esta versão é aconselhado a seguir as recomendações acima para limitar sua vulnerabilidade.

Estamos trabalhando nas mudanças para a versão 3.4 e teremos um novo pacote disponível para download o mais breve possível. Quando disponíveis, os novos pacotes poderão ser obtidos em:

http://www6.software.ibm.com/dl/aixtbx/aixtbx-p

Esta página contém as aplicações Linux Affinity que possuem algoritmos criptográficos e é solicitado que novos usuários desta página registrem-se primeiro.

Lotus

Os produtos Lotus não são vulneráveis a este problema.

Mandrake Software

A MandrakeSoft lançou o OpenSSH 3.3p1 nas atualizações de segunda à noite para minimizar estas vulnerabilidades. Atualizações para o OpenSSH 3.4p1 estarão disponíveis para download ao final desta semana.

Microsoft Corporation

Os produtos Microsoft não são afetados pelos problemas detalhados neste advisory.

Network Appliance

Os sistemas NetApp não são vulneráveis a este problema.

OpenBSD

Veja http://www.openbsd.org/errata.html#sshd

OpenSSH

Veja http://www.openssh.com/txt/preauth.adv

Process Software

MultiNet, TCPware e SSH para OpenVMS não são afetados pelos problemas descritos neste advisory.

RedHat Inc.

As versões 7, 7.1, 7.2 e 7.3 do Red Hat Linux, assim como a versão 2.1 do Red Hat Linux Advanced Server, são distribuídas com o OpenSSH. Os pacotes OpenSSH do Red Hat Linux não são compilados com as opções BSD_AUTH ou SKEY habilitadas, portanto para estar vulnerável a este problema um usuário necessitaria ter habilitado a opção de configuração "PAMAuthenticationViaKbdInt" em seu arquivo de configuração do sshd (o padrão é estar desabilitado).

Continuaremos a investigar estas vulnerabilidades e lançaremos pacotes de atualizações quando apropriado.

SGI

Até o momento a SGI não distribui o OpenSSH como parte do IRIX.

O código de separação de privilégios do OpenSSH, em sua maior parte funciona com o IRIX, mas este utiliza uma flag do mmap para compressão que não está no IRIX (MAP_ANON), deste modo você não pode ter ambos ligados ao mesmo tempo. O IRIX não é distribuído com PAM, assim os problemas relacionados com o PAM não são problemas para nós.

O CERT Coordination Center agradece a Theo de Raadt e a Markus Friedl, do projeto OpenBSD, pela assistência técnica na produção deste advisory.

Autor: Cory F. Cohen

Informações de Contato do CERT/CC

Email: cert@cert.org

Telefone: +1 412-268-7090 (Hotline 24 horas)

Fax: +1 412-268-6989

Endereço para correspondência:

CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh PA 15213-3890
U.S.A.

O pessoal do CERT/CC atende ao hotline no período das 8:00 às 17:00h EST(GMT-5), de segunda a sexta-feira; nos demais períodos eles atendem em esquema emergencial, incluindo finais de semana e feriados dos Estados Unidos.

Utilização de criptografia

Nós recomendamos fortemente que informações sensíveis sejam criptogradas ao serem enviadas por email. Nossa chave pública PGP está disponível em:

• http://www.cert.org/CERT_PGP.key

Se você preferir utilizar DES, por favor telefone para o hotline do CERT para obter maiores informações.

Obtendo informações sobre segurança

As publicações do CERT e outras informações sobre segurança estão disponíveis em nosso site:

• http://www.cert.org/

Para inscrever-se na lista de advisories e boletins do CERT, envie um email para majordomo@cert.org, incluindo o seguinte no corpo da sua mensagem:

subscribe cert-advisory

* "CERT" and "CERT Coordination Center" are registered in the U.S. Patent and Trademark Office.

Translations of CERT/CC Advisories, (c) 2002 by Carnegie Mellon University, with special permission from the Software Engineering Institute.

Accuracy and interpretation of this translation are the responsibility of NBSO. The SEI has not participated in this translation.

NBSO shall ensure that all translated materials incorporate the CERT/CC logos, service marks, and/or trademarks, as well as a link to the original English version on the CERT web site (www.cert.org).

NBSO shall ensure that all translated materials are translated in their entirety and that the SEI will be notified of which CERT/CC Advisories are being translated. Notifications go to cert@cert.org.

NO WARRANTY. THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED ON AN "AS IS" BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT.

CMU Indemnification. NBSO hereby agrees to defend, indemnify, and hold harmless CMU, its trustees, officers, employees, and agents from all claims or demands made against them (and any related losses, expenses, or attorney's fees) arising out of, or relating to NBSO's and/or its sublicensees' negligent use or willful misuse of or negligent conduct or willful misconduct regarding CMU in tellectual Property, facilities, or other rights or assistance granted by CMU under this Agreement, including, but not limited to, any claims of product liability, personal injury, death, damage to property, or violation of any laws or regulations. This indemnification will not apply to claims by third parties which allege that CMU Intellectual Property infringes on the intellectual property rights of such third parties, unless such infringement results from NBSO modifying CMU Intellectual Property or combining it with other intellectual property.

Disputes. This Agreement shall be governed by the laws of the Commonwealth of Pennsylvania. Any dispute or claim arising out of or relating to this Agreement will be settled by arbitration in Pittsburgh, Pennsylvania in accordance with the rules of the American Arbitration Association and judgment upon award rendered by the arbitrator(s) may be entered in any court having jurisdiction.

No Endorsement. The SEI and CMU do not directly or indirectly endorse NBSO work.

Translations of CMU/SEI copyrighted material are not official SEI-authorized translations. NBSO agrees to assign and transfer to CMU/SEI all copyrights in the translation of any CMU/SEI document.

This permission is granted on a non-exclusive basis for non-commercial purposes.

Conditions for use, disclaimers, and sponsorship information

Copyright 2002 Carnegie Mellon University.

Histórico de Revisões
26 de junho de 2002: Lançamento da versão inicial