A maioria das árvores do linux-next está inacessível devido ao problema no kernel.org
Para os curiosos e interessados a respeito da situação que vem se desenrolando há quase um mês com a indisponibilidade do kernel.org devido a uma invasão ocorrida no final de agosto, eis mais um elemento de informação: embora a merge window do Linux 3.2 esteja se aproximado e tenha ocorrido uma migração para o github, um desenvolvedor do linux-next informou que das mais de 170 árvores que representam o trabalho para ela, 89 existem apenas nas máquinas do kernel.org e assim, naturalmente, não puderam ser atualizadas ao longo de todo este período. A conclusão natural é que há uma interrupção considerável nas análises e testes, se não no desenvolvimento do código correspondente; será interessante acompanhar os efeitos posteriores. (via lwn.net – “89 trees missing from linux-next [LWN.net]”)
@brlinuxblog
Feed RSS
Isso mostra que o impacto no andamento dos trabalho está sendo bem maior que o imaginado.
Mas vamos levar pelo lado positivo. Sistema 100% seguro não existe. Espero que dessa experiência saiam melhorias nos processos de desenvolvimento do kernel. Que sirva de aprendizado para melhorar.
Pelo jeito, essa falha de segurança é antiga, mas ninguém tinha descoberto e explorado. E aparentemente até agora não conseguiram encontrá-la.
@Marcos,
Não era uma falha de segurança. ELes conseguiram acesso ao shell do servidor através do abuso de uma senha de um dos desenvolvedores.
Contra a ignorância humana não há patch.
@Dornival, se fosse só isso, seria apenas mudar a senha de todo mundo. Pra demorar tanto, é porque tem muito mais coisa aí.
@Marcos você pode estar correto o kernel ficou 8 anos com um bug grave de segurança. Antes que eu me esqueça o Windows teve um bug que durou 17 anos …
@Dornival
Você está mal informado. O começo do problema foi a senha. Mas há uma falha desconhecida que possibilitou a escalada de privilégios até o usuário se tornar root.
@ Fabio Lima “Sistema 100% seguro não existe.”
Mas existem sistemas “mais” seguros.
“Pelo jeito, essa falha de segurança é antiga, mas ninguém tinha descoberto e explorado. E aparentemente até agora não conseguiram encontrá-la.” – Marcos
Textbook definition para um Zero-Day exploit. Se me perguntarem foi isso que aconteceu.
Por isso a demora. O pessoal do Kernel.org está louco tentando descobrir o que era. Forense Computacional deve estar sendo pesada em cima das informações dos servidores, para prevenir que aconteça em outros lugares.
Só que o pessoal tá esquecendo da restauração do serviço, que é uma parte tão importante quanto essa. O que por si só é esquisito. Afinal, se a falha requeria acesso à um shell, por que não levantaram o servidor? Será que algo mais foi comprometido? Será que a falha é diferente do que achamos?
Esta comprovado ou leitor br-linux não lê; hum que estranho leitor que nao lê; ou tem a memória muito curta, a demora para a volta do serviço é por alguns motivos:
1. Claro que eles querem investigar ao máximo como a catástrofe aconteceu;
2. Esta sendo modificada a estrutura dos (~100) servidores.
3. A demora não tem problema uma vez que o git é um versionador distribuido;
@afasffaf, não acho que eu esteja mal informando, mesmo porque eu só vi essa sua afirmação vindo de fontes não confiáveis, mas caso você me indicar a referência eu acredito :)
@Marcos, eu concordo parcialmente com você; caso a senha de um desenvolvedor tenha sido comprometida, e posteriormente as senhas dos demais também, não trata-se apenas de modificá-las. Não se sabe ao certo o que o atacante fez nos servidores. As boas práticas mandam reinstalar todos os sistemas neste caso.
E não podemos esquecer que são em torno de 100 servidores.
Observação, não me lembro aonde li (talvez aqui mesmo), mas estavam querendo deixar de usar o git+ssh para uma versão modificada de shell que não permite que o usuário use o shell de fato, mas apenas consiga comunicar-se utilizando o protocolo do git.
Segundo, se a pessoa deixou tudo “APENAS” no kernel.org se fud… bonito. Agora minha dúvida é como que está tudo “APENAS” no kernel.org se o git é distribuido?
A conclusão que se tira disso é que:
1- A tal pessoa apagava tudo após fazer o push para o kernel.org, logo, para o ser humano realmente não existe patch.
2- A pessoa não versionava e deixava tudo em um punhado de arquivos .tar.gz, logo, para o ser humano realmente não existe patch.
3- A pessoa não têm a menor noção do que é o GIT, logo, para o ser humano realmente não existe patch.
4- O HD do computador de trabalho foi pro saco, nesse caso o kernel.org realmente está fazendo falta.
@Rodrigo P. Matias
Mesmo assim é estranho. Não é mais o momento para uma análise live, então já deveriam ter feito imagens (ou trocado os HDs) e reinstalado.
Não existe esse tipo de análise tão demorada assim, que impeça o retorno deste serviço.