Violação de segurança: agora é no Linux.com e LinuxFoundation.org
Lembra da violação de segurança no site kernel.org que noticiamos no início do mês? Aparentemente (caso se confirme a suposição de interconexão dos fatos mencionada pela Linux Foundation) ela deu mais um fruto amargo: violações adicionais da segurança dos servidores dos domínios Linux.com e LinuxFoundation.org.
O alerta enviado aos usuários é de que logins, senhas, endereços de e-mail e outras informações que tenham sido confiadas à Linux Foundation devem ser considerados como comprometidos, e se as mesmas senhas forem usadas em outros sites, elas devem ser trocadas imediatamente.
No momento em que escrevo, uma auditoria está em andamento, com o compromisso de divulgar mais informações assim que estiverem disponíveis. Também está ocorrendo uma investigação em cooperação com autoridades dos EUA e Europa. Como parte do procedimento, todos os servidores da Linux Foundation foram tirados do ar para a realização de reinstalações completas. Os serviços da Fundação voltarão ao ar conforme estes servidores forem reativados. (via lwn.net)
@brlinuxblog
Feed RSS
Sites internet sofre com estes problemas, mas… sites grandes assim não passam por auditoria todo ano???? OOo Auditorzinho, ou não vai saber. Vai que é uma zero-day. Antes da investigação não da para culpar ninguém.
Lembrei dos episódios com alguns servidores do(a) Debian.
http://br-linux.org/noticias/001411.html
http://br-linux.org/linux/seguranca_comprometida_em_um_dos_servidores_do_projeto_debian
Está na hora de instalar um OpenBSD nesses servidores, hehe.
A coisa só tá ficando pior. Ainda bem que não é algum vírus/trojan/worm se instalando nos computadores das pessoas, e sim só violação de sites (provavelmente algum cracker se achando…), o que não me deixa TÃO preocupado.
Pois é, e até hoje o kernel.org está “down”.
Deve ser o mesmo Zero-Day que usaram no Kernel.org.
Enquanto isso, eu vou vestir a camisa do “Já Sabia”: “Potencialmente tem uma vulnerabilidade zero-day passeando por aí, custando muito mais barato que o que foi pago pelo primeiro uso. Os sysadmins deviam levantar a guarda até descobrirem o que houve.”http://br-linux.org/2011/violacao-da-seguranca-no-kernel-org/#comment-133808
Quem não costuma ser alvo de ataque também não costuma se proteger muito. Acho que depois desses episódios, os sysadmins responsáveis serão mais cautelosos.
Pelo que entendi, o problema não é uma invasão direta.
E sim alguém que roubou (ou foram cedidas concientemente por alguém mal intencionado) os dados de acesso com alguém com priviégios consideráveis.
Invasão, cagada de sysadmin, roubo de senha ou o que quer que seja, vamos esperar o término da auditoria antes de apedrejar alguém!
Como diz o Filipe…. OpenBSD neles!!!!
é mais dificil,
é antigo,
não é modular,
é lento…
mas é seguro…
@Edu, no Kernel.org foram 2 problemas. 1- O comprometimento de uma conta com acesso ao shell do servidor (o que é sempre grave) 2- De uma forma desconhecida (na época) o invasor escalou privilégios e se transformou em Root.
Isso é bem grave.
Kct.. O kernel.org está down até agora.. sera que um dia volta???
Down por quanto tempo? meses??? como diz aquele cara da TV.
isso é uma v……
Pelo menos deveriam colocar no ar em OpenBSD por enquanto…
Essas falhas de dia zero complicou mesmo não só a minha vida como também de outros que precisam. Me entregaram uma impressora laser HP para instalar em um Desktop Ubuntu e, na hora de plugar, pede um plugin do openprinting.org que justamente é um dos sites que foram afetados nesta notícia. Agora estou caçando o hplip-3.11.1-plugin.run e o google só retorna o site que está fora e não achei nenhum mirror até agora :/
Tem um cópia da árvore do kernel no github, entäo o kernel.org estar fora näo é um grande problema.
É muito melhor encontrar a real causa do problema, demore o tempo que demorar, e aí sim voltar com tudo no kernel.org
http://lkml.org/lkml/2011/9/4/92
https://github.com/torvalds/linux
O povo do baboo e do meiobit estão fazendo festa…
A falha é grave, sim. O fato do kernel.org estar tanto tempo fora do ar é a prova maior disso. Se fosse algo simples, já teriam voltado e até corrigido.
Espero que não demorem, a imagem do Linux está sendo comprometida.
Senhor
Impressão sua são os isentos, só querem “a melhor ferramenta sempre”.
Não se envolvem emocionalmente.
Ahan… ;)
Marcos, eu discordo.
De nada adianta voltar ao ar rapidamente, sem entender o que realmente aconteceu.
É preferível sim manter os sources no github, até que todos os servidores do kernel.org sejam revisados, reinstalados, ou seja lá qual for o procedimento escolhido.
Acredito que nao sejam poucos os servidores, talvez por isso esse tempo mais longo…
Ou talvez realmente a causa raiz nao foi encontrada…
Enfim, nao é o fim do mundo. Talvez alguém esqueceu de aplicar algum patch, ou algo do tipo…
http://nakedsecurity.sophos.com/2011/09/12/linux-world-in-security-spinout/
http://www.theregister.co.uk/2011/08/31/linux_kernel_security_breach/
Tem mais gente pensando em utilizar o OpenBSD :)
Será?
http://br-linux.org/2010/desenvolvedor-acusa-fbi-de-colocar-backdoor-no-ipsec-do-openbsd/
Ninjacatnoob, algo foi comprovado? O openbsd.org está no ar…
http://lwn.net/Articles/458414/
Isso está sendo um grande golpe moral.
Como já disseram isso denigre profundamente a imagem do projeto.
Até a Skynet caiu nas gurras do John Connor. :P
Se for para não usar o Linux melhor migrar para servidores windows. Daí é só colocar a culpa na microsoft como sempre.
Tecnicamente falando o OpenBSD é considerado pouco escalável e não “lento” como alguns aqui pensam. E ele também tem modulos de kernel;
http://www.openbsd.org/cgi-bin/man.cgi?query=lkm&sektion=4&format=html
É claro que fica muito fácil depois do ocorrido se criticar, mas não vou me fazer de rogado :) Se não serve mais como previsão, pelo menos fica como lição:
Tava na cara (como disse fica fácil prever o que já é passado :) que se o kernel.org foi comprometido usando um login válido, há uma alta possibilidade do mesmo login, ser usado em sites relacionados (e como são relacionados!). Então um admin pró-ativo já teria verificado se pelo menos o login igual ao que foi usado no kernel.org estaria em uso no seu próprio site, podendo, e devendo, estender a busca à chave pública (usada no SSH) do login comprometido.
É claro que isso não iria resolver o problema de escalação de privilégio, mais ia dar mais tempo para o problema do kernel.org ser encontrado e resolvido.
Acho prematuro culpar o kernel pelo problema, pode ser algum outro software responsável pela escalação de privilégio.
Alguém sabe que distribuição os sites usavam?
Boa a piada de usar OpenBSD, mas acho que se o problema não foi encontrado variar as coisas é legal, tipo arquitetura dos servidores, versões dos softwares envolvidos, distros e kernels.
@Xinuo
“Acho prematuro culpar o kernel pelo problema, pode ser algum outro software responsável pela escalação de privilégio.”
http://quigon.bsws.de/papers/2010/bsdcan/mgp00048.html
“Boa a piada de usar OpenBSD…”
Claro que é, não tem instalador gráfico.
@Filipe, se fosse somente isso, não demoraria tanto tempo fora do ar, isso é fato.
Felizmente, no lugar de ficar tentando minimizar o ocorrido ou tentando colocar a sujeira por baixo do tapete, eles estão empenhados em resolver.
@kashmir, se existe um executável set[g]uid dando poderes demais e ele tiver um bug, o que o kernel têm a ver com isso?
Entendi o conselho do slide que vc mandou mas não me pareceu confrontar minha afirmação, embora mostre como o desenvolvedor deve pensar para diminuir, isolar e limitar os problemas com relação a escalação.
Sobre a outra afirmação que vc grifou, usei o termo “piada” pois diversos comentaristas sugeriram isso com “tom” de piada, não “contra” o OpenBSD e sim “contra” o Linux. Mas no desenrolar do parágrafo sugeri que variassem de kernel também, ou seja, concordei como sendo uma possível alternativa.
Apesar de um ambiente homogêneo ser mais fácil administrar, não creio que os sites atingidos façam algo que seja exclusivo de distros GNU ou BSD, então um ambiente heterogêneo seria uma solução (paliativa?) para diminuir a probabilidade de uma falha num sistema ser facilmente explorado em outro e se ter todo o parque de servidores indisponíveis. É uma possível solução para a afirmação (não provada) de que “não existe linguagem ou ambiente absolutamente seguro”.
Nem o vírus Ébola mata 100% dos infectados (só 90%), é a heterogeneidade agindo a nosso favor.
Pois é, aos amadores do linux e dos que tanto falavam que o Linux era impossivel violar, ai vem as provas, hoje nada é impossível violar.
@Xinuo
Sim cara, o slide não confronta sua afirmação e nem eu o fiz. Mas acontece que se o problema for mesmo um executável set[g]uid a integração entre o Linux (kernel) e o GNU/Linux (sistema) precisará ser repensada, a corrente é tão boa quanto seu elo mais fraco. Imagine a sinuca de bico em que os caras do kernel podem se meter ao dar um puxão de orelhas nos desenvolvedores de executáveis setuid, ou seja lá qual software for o software culpado.
Sobre ambientes heterogênoes, já imaginou qual seria a credibilidade do GNU/Linux se eles rodassem em um Solaris só para diminuir a probabilidade de explorações desse tipo?