 |
|
|
Um histórico completo das revisões pode ser encontrado ao final deste documento.
Existe uma vulnerabilidade no sendmail que pode permitir que atacantes remotos ganhem privilégios do daemon sendmail, normalmente root.
Pesquisadores da Internet Security Systems (ISS) descobriram uma vulnerabilidade no sendmail que pode ser explorada remotamente. Esta vulnerabilidade pode permitir que um atacante ganhe o controle de um servidor sendmail vulnerável.
A maior parte das organizações possui diversos MTAs (mail transfer agents) em diversas localizações dentro de sua rede, sendo pelo menos um deles exposto à Internet. Uma vez que o sendmail é o MTA mais popular, boa parte das organizações de médio a grande porte provavelmente possuem ao menos um servidor sendmail vulnerável. Somado a isto, diversas estações de trabalho UNIX e Linux possuem na sua instalação padrão uma implementação de sendmail habilitada e em execução.
Esta vulnerabilidade é orientada a mensagens, em oposição àquelas orientadas a conexão. Isto significa que a vulnerabilidade é disparada pelo conteúdo de uma mensagem de email especialmente construída, ao invés de tráfego de rede em baixo nível. Isto é importante porque um MTA que não possui a vulnerabilidade passará a mensagem maliciosa para outros MTAs que podem estar protegidos no nível de rede. Em outras palavras, servidores sendmail vulneráveis no interior de uma rede estão em risco mesmo que os servidores MTA de borda utilizem outros softwares que não o sendmail. Além disso, mensagens capazes de explorar esta vulnerabilidade podem passar sem ser detectadas através de vários firewalls ou filtros de pacotes.
A Sendmail informou ao CERT/CC que esta vulnerabilidade foi explorada com sucesso em ambiente de laboratório. Nós não acreditamos que este "exploit" esteja disponível para o público. Entretanto, esta vulnerabilidade provavelmente chamará a atenção da comunidade de invasores, deste modo a probabilidade de surgir um "exploit" público é grande.
Um ataque bem sucedido contra um sendmail sem correções não deixará nenhuma mensagem nos logs do sistema. Entretanto, em um sistema com as correções, uma tentativa de explorar esta vulnerabilidade deixará a seguinte mensagem nos logs do sistema:
Dropped invalid comments from header address
Apesar disto não representar uma evidência conclusiva de um ataque, pode ser útil como uma indicação de sua ocorrência.
Um sendmail com as devidas correções descartará cabeçalhos inválidos, prevenindo deste modo que servidores internos os recebam.
O CERT/CC está catalogando este problema como VU#398025. Este número de referência corresponde ao número CAN-2002-1337 do CVE.
Para maiores informações, por favor consulte:
A exploração bem sucedida desta vulnerabilidade pode permitir a um atacante conseguir os privilégios do "daemon" sendmail, normalmente root. Mesmo os servidores sendmail internos a uma dada rede poderão estar em risco, uma vez que a vulnerabilidade é disparada a partir do conteúdo de um email malicioso.
A Sendmail produziu correções para as versões 8.9, 8.10, 8.11 e 8.12. Entretanto, a vulnerabilidade também existe em versões mais antigas do código. Deste modo, os administradores que estiverem utilizando versões mais antigas são encorajados a atualizá-las para a versão 8.12.8. As correções estão disponíveis em:
Muitos fornecedores incluem servidores sendmail vulneráveis como parte de suas distribuições. Nós notificamos os fornecedores sobre esta vulnerabilidade e colocamos suas respostas na seção de sistemas afetados da "Vulnerability Note" VU#398025. Diversos fornecedores enviaram declarações para inclusão direta neste "advisory". Estas declarações estão disponíveis no Apêndice A.
Não existe nenhuma solução paliativa para esta vulnerabilidade. Até que uma correção possa ser aplicada você pode querer habilitar a opção RunAsUser para reduzir o impacto desta vulnerabilidade. Como uma boa prática, o CERT/CC recomenda limitar os privilégios de uma aplicação ou serviço sempre que possível.
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.
O "Security Update 2003-03-03" está disponível para corrigir este problema. Estão disponíveis pacotes para os sistemas Mac OS X 10.1.5 e Mac OS X 10.2.4. Deve-se notar que o sendmail não está habilitado na instalação padrão do Mac OS X, deste modo, somente aqueles sistemas que o tiverem habilitado explicitamente estarão suscetíveis a esta vulnerabilidade. Entretanto, todos os usuários de Mac OS X são encorajados a aplicar esta atualização em seus sistemas.
A Avaya está ciente desta vulnerabilidade e está investigando seu impacto. Conforme novas informações estejam disponíveis, esta seção será atualizada.
A Wind River Systems criou correções para este problema que estão disponíveis nos locais usuais para cada "release". As correções relevantes são a M500-006 para o BSD/OS versão 5.0 ou para o "Wind River Platform for Server Appliances 1.0", a M431-002 para o BSD/OS 4.3.1 ou a M420-032 para o BSD/OS 4.2.
A Cisco está investigando este problema. Se nós determinarmos que algum de nossos produtos está vulnerável esta iformação estará disponível em: http://www.cisco.com/go/psirt.
O código fornecido pela Cray, Inc. nos sistemas Unicos, Unicos/mk e Unicos/mp pode estar vulnerável. A Cray abriu os SPRs 724749 e 724750 para investigar. Cray, Inc. não é vulnerável para os sistemas de MTA.
ORIGEM:Hewlett-Packard Company HP Services Software Security Response Teamx-ref: SSRT3469 sendmail
A HP anunciará a disponibilidade de correções através dos anúncios do "security bulletin" e através dos canais normais de suporte do HP Services.
O sistema operacional AIX é vulnerável ao problema do sendmail nas versões 4.3.3, 5.1.0 e 5.2.0.
Uma correção temporária está disponível através de um pacote "efix", que pode ser encontrado em: ftp://ftp.software.ibm.com/aix/efixes/security/sendmail_efix.tar.Z
A IBM proverá as seguintes correções oficiais:
- Número do APAR para o AIX 4.3.3: IY40500 (disponível aprox. em 12/03/2003)
- Número do APAR para o AIX 5.1.0: IY40501 (disponível aprox. em 28/04/2003)
- Número do APAR para o AIX 5.2.0: IY40502 (disponível aprox. em 28/04/2003)
O Openwall GNU/*/Linux não é vulnerável. Nós usamos o Postfix como MTA e não sendmail.
Pacotes atualizados do sendmail, que não estão vulneráveis a este problema, estão disponíveis para o "Red Hat Linux", para o "Red Hat Advanced Server" e para o "Red Hat Advanced Workstation". Os usuários do serviço Red Hat Network poderão atualizar seus sistemas utilizando a ferramenta 'up2date'.
Red Hat Linux:
http://rhn.redhat.com/errata/RHSA-2003-073.htmlRed Hat Linux Advanced Server e Advanced Workstation:
http://rhn.redhat.com/errata/RHSA-2003-074.html
A SGI tomou conhecimento da VU#398025 notificada pelo CERT e lançou um advisory para tratar desta vulnerabilidade no IRIX.
Referencie-se ao "SGI Security Advisory 20030301-01-P", disponível em: ftp://patches.sgi.com/support/free/security/advisories/20030301-01-P ou http://www.sgi.com/support/security/.
O Sendmail Consortium sugere que os sites façam uma atualização para a versão 8.12.8 se possível. De maneira alternativa, estão disponíveis correções para as versões for 8.9, 8.10, 8.11 e 8.12 em http://www.sendmail.org/.
Todas as versões comerciais, incluindo "Sendmail Switch", "Sendmail Advanced Message Server" (que inclui o "Sendmail Switch" MTA), Sendmail para NT e Sendmail Pro, são afetadas por este problema. Informações sobre as correções estão disponíveis em http://www.sendmail.com/security.
As versões de Solaris 2.6, 7, 8 e 9 são vulneráveis à VU#398025.
A Sun publicará um Alerta para este problema, que estará disponível em breve em:
http://sunsolve.Sun.COM/pub-cgi/retrieve.pl?doc=fsalert/51181As correções listadas no Alerta da Sun estarão disponíveis em:
http://sunsolve.sun.com/securitypatch
Nossos agradecimentos para a Internet Security Systems, Inc. por ter descoberto este problema e para Eric Allman, Claus Assmann e Greg Shapiro da Sendmail por nos notificarem deste problema. Nós agradecemos ambos os grupos pela sua assistência na coordenação da resposta a este problema.
Autores: Jeffrey P. Lanza e Shawn V. Hernan
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.
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:
Se voce preferir utilizar DES, por favor telefone para o hotline do CERT para obter maiores informações.
As publicações do CERT e outras informações sobre segurança estão disponíveis em nosso site:
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) 2003 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.
Copyright 2003 Carnegie Mellon University.
Histórico de Revisões
03 de março de 2003: Lançamento da versão inicial 03 de março de 2003: Inclusão da declaração da Sun Microsystems