Bug grave do compilador GCC Linux deixa servidores vulneráveis
Os problemas de segurança dos sistemas Linux surgiram em força durante o ano de 2014. Vários foram os problemas graves e que mostraram as fragilidades de sistemas que se julgavam seguros.
Mas 2015 parece não querer ser diferente do ano anterior e uma nova vulnerabilidade surgiu. O Ghost foi agora anunciado e vem colocar em risco qualquer servidor Linux.
Este novo bug descoberto agora está provavelmente presente em qualquer servidor Linux e representa uma falha de segurança grave. Se devidamente explorado o Ghost consegue dar ao atacante acesso à máquina remota onde depois pode correr qualquer código que entenda.
A falha reside num buffer overflow que é feito na função __nss_hostname_digits_dots() da glibc. Esta função é chamada sempre que outras duas são invocadas - gethostbyname() e gethostbyname2() - e que servem para fazer a tradução de nomes DNS em endereços IP.
Qualquer atacante que consiga invocar uma dessas duas funções consegue explorar a falha e e executar código aleatório com as permissões do utilizador que está a correr a aplicação.
Por o GCC ser uma ferramenta que é usada em quase todos os sistemas Linux a falha tem um impacto grande e está de certeza presente na maioria dos servidores onde este sistema corre.
Não existe também um serviço específico onde o problema se manifeste, estando mais uma vez presente na maioria dos serviços que esses servidores alojam, desde o email até às páginas web.
O Ghost e o problema que apresenta pode ser entendido no vídeo que apresentamos abaixo, da autoria do investigador que descobriu este problema.
A falha foi detectada numa avaliação de segurança da empresa Qualys que a anunciou. Antes de tornar público o Ghost, a Qualys contactou e trabalhou de perto com as equipas das principais distribuições Linux para que fossem disponibilizadas actualizações ao GCC e às bibliotecas afectadas por este problema.
Segundo o que foi descoberto o problema existe há já alguns anos, com a versão do GCC onde primeiro se manifesta a ser a 2.2 (glibc-2.2), lançada a 10 de Novembro de 2000.
As actualizações dos diferentes sistemas estão na sua maioria disponíveis É por isso importante que todos os sistemas sejam actualizados, mesmo os mais recentes. As actualizações de segurança começaram a ser disponibilizadas no dia 27 de Janeiro.
A interligação e a dependência dos sistemas Linux com o GCC é grande, sendo esta biblioteca essencial para o funcionamento dos sistemas. A sua presença nos servidores Linux é quase certa na sua quase totalidade.
A necessidade de reiniciar os sistemas após a instalação da nova versão do GCC será com certeza um entrave à sua rápida actualização, mesmo isso deixando os sistemas vulneráveis.
Reforçamos da necessidade de instalação das actualizações ao GCC que todas as distribuições Linux lançaram, para que os sistemas fiquem protegidos e sem a vulnerabilidade que o Ghost representa.
Este artigo tem mais de um ano
Caros, a vulnerabilidade está na implementação do glibc, não go gcc.
O que eu acho interessante nestas descobertas, é que apesar de serem corrigidas com actualizações, são falhas que já existem quase desde sempre.
E são prova evidente, que o sistema Linux nunca foi interessante por parte de hackers, provavelmente por ter uma cota de mercado muito baixa. Caso contrario, o sistema tinha enfrentado mais problemas ao longo da sua vida.
A falha está corrigida há 2 anos…. O problema é somente as distribuições que não actualizaram para uma versão da GLIBC mais recente que isso.
Independentemente de estar corrigido há 2 anos, o Linux não existe apenas a 3 anos. Esta falha, já existe muito mais anos no sistema. E nem estou em por em causa a sua correcção.
O que eu queria dizer, é que as mais recentes revelações sobre diversos bugs que o Linux tinha/teve durante bastante tempo, nunca foram aproveitadas por hackers.
Isso mostra, que este sistema nunca foi aliciante para esse tipo de pessoas, que tentam lucrar com as falhas dos sistemas. Isso indica que este sistema não tem sofrido tantos ataques, porque a cota de mercado não é suficientemente alta, para justificar meios gastos por hackers na exploração de bugs.
O que não falta para aí são servidores com Linux instalados 🙂
Por acaso sabes a quota de servidores a correr linux? Olha que estamos a falar de servidores e não de desktops.
É verdade. perto de 90% dos servidores que existem no mundo são linux.
Nem mais!
“provavelmente por ter uma cota de mercado muito baixa”
Em servidores?
não é da cota do mercado, mas sim da filosofia, pois a cota de servidores e supercomputadores a correr linux é assustadoramente grande
Fuck off men…Estas louco ou quê?! Todos os servidores que conheço são Linux. OMG :X (facepalm)
Tal como muitos erros descobertos noutros SO que já existiam à vários anos.
infelizmente com o teu comentário só provaste a tua ignorância.
Um coisa é o compilador e outra coisa é a biblioteca de funções!
+1
Verdade. A falha é na Bibliotec LIBC6 (GLIBC) e não no compilador.
Nem todas as máquinas linux precisam ter o compilador GCC instalado, porém a grande maioria das aplicações precisam da biblioteca e esta é quem está vulnerável e deve ser atualizada.
Exacto.
Acredito que para explorar essa falha iria precisar da autenticação do usuario, no linux existe um forte permissionamento pras coisas, o que não tornaria muito fácil explorar um servidor.
ja saiu a atualização pra corrigir esse problema?
Sim, há 2 anos…
No repositório do código fonte da biblioteca a correção saiu em 2013, mas na maioria das distribuições usadas em servidores de produção, a correção para o pacotes saiu só dia 27/01/2015.
A menos que você tenha compilado a biblioteca a partir dos fontes, o que provavelmente não o fez, você estava vulnerável.
Posso-te garantir que não estava…
Segundo o changelog do Arch (https://projects.archlinux.org/svntogit/packages.git/log/trunk?h=packages/glibc) o glibc 2.18 foi disponibilizado em Agosto de 2013 (já com o fix portanto). Desde essa altura que estou protegido.
Não percebo como há distro que ainda usam glibc 2.5, 2.6 e 2.10…. Mas isso são outros 500.
Arch Linux é excessão, por que é rolling release.
Mas a participação dele em servidores de produção e de serviços que são homologados para ele são bem menores que as distribuições tradicionais.
Segue a lista de distribuições afetadas até dia 27/01/2015.
RHEL (Red Hat Enterprise Linux) version 5.x, 6.x and 7.x
CentOS Linux version 5.x, 6.x & 7.x
Ubuntu Linux version 10.04, 12.04 LTS
Debian Linux version 7.x
Linux Mint version 13.0
Fedora Linux version 19 or older
SUSE Linux Enterprise 11 and older (also OpenSuse Linux 11 or older versions).
SUSE Linux Enterprise Software Development Kit 11 SP3
SUSE Linux Enterprise Server 11 SP3 for VMware
SUSE Linux Enterprise Server 11 SP3
SUSE Linux Enterprise Server 11 SP2 LTSS
SUSE Linux Enterprise Server 11 SP1 LTSS
SUSE Linux Enterprise Server 10 SP4 LTSS
SUSE Linux Enterprise Desktop 11 SP3
Slackware 14.1
Não estou a dizer que não tens razão, só estou a dizer que estou protegido há muito tempo. Felizmente, não vejo nessa lista nem Gentoo, nem Arch.
O pessoal gosta de usar versioning distros, eu não gosto, e simplesmente desaconselho. Até em servidores.
É um falha que pode ser explorada remotamente, sem autenticação.
É uma falha com resolução de nomes, muito provavelmente você manda o servidor resolver um nome com algum caractere de escape que faz com que seja convertido em um código abitrário em memória.
É mais uma machadada no mito dos muitos olhos.
A teoria é boa, na prática fica claro que ninguém realmente olha para o código.
Para complementar a notícia: o bug já estava identificado há muito, apenas não estava classificado como crítico e como tal não era resolvido, apenas a Google o fez no Chrome OS.
Identificado e *corrigido*… Há 2 anos!
Não foi só o Google, muita gente corrigiu, como o Arch Linux, Ubuntu 14 e muitos outros.
Porém muitas distrubições mais conservadoras como o Centos e RH que demoram a liberar versões novas dos pacotes ainda estavam vulneráveis, além de versões mais antigas mas ainda suportadas como o caso do do Ubuntu 12.10.
Perceba que a Qualys, a empresa que alertou sobre o problema, descobriu isso, porquê estava fazendo auditoria no código fonte.
Se não tivesse o código fonte ficaria bem mais difícil descobrir determinados bugs.
Em suma, o que disseste é na verdade um contra-argumento, pois com mais os olhos da Qualys, foi encontrado o bug.
Em tempo: na verdade o bug foi corrigido há anos atrás, a Qualys descobriu como explorar o bug, que na época da descoberta não foi classificado crítico, pois não se sabia como explorá-lo (e nem se sabe ainda, pois a Qualys não revelou).
Como e onde sabemos se este bug já foi corrigido?
O bug foi corrigido há 2 anos atrás. Algumas distribuições, normalmente usadas em servidores é que demoraram a corrigir, pois o bug, quando foi descoberto, não foi considerado crítico.
Só agora em jan/2015 é que o bug foi reclassificado como crítico, pois uma empresa (Qualys) que estava fazendo auditoria no código fonte, descobriu uma maneira de explorar a falha de modo contundente. Assim reclassificado, as distribuições, que não tinham corrigido, lançaram as versões da glib com correção.
Se estás a usar uma distribuição de desktop (Fedora, Ubuntu, OpenSuSE, etc.) provavelmente já está atualizada (desde que seja uma instalação e versão recente <2 anos). Se estás a usar uma distro de servidor (RedHat, CentOS, Debian, Ubuntu LTS, SuSE, etc.), basta que atualize a glibc e o kernel (mas já que vai ser necessário boot é bom atualizar tudo que tenha para atualizar).
Eu uso Debian Jessie, kernel 3.17-1, portanto já deve estar mais que corrigido. E não é distro de servidor.
O pplware deveria ponderar se deve ou não escrever noticias sobre segurança no futuro. Não mandam uma para a caixa. Que desastre…
E a que se deve esse infeliz comentário? Fazes melhor? Ainda não vi nada!
Se não gostas, porque te dás sequer ao trabalho de cá vires??? Principalmente para colocar posts destes quem em nada contribuem para a comunidade. Ao menos explica-te, mas dá-te ao respeito pelas pessoas que tentam fazer o melhor que sabem/podem!
Já todos sabemos que o bug é no (lib)glibc. De resto, não vejo o propósito do teu comentário descabido!
Durante a ultima actualização do Lubunto, aquando do update do kernel, no terminal apareceram varios erros de memory leak. A maquina ficou lenta a partir do reboot, parece que fica a mastigar durante o arranque. No log, aparecem bastantes erros.