Visite também: Currículo ·  Efetividade BR-Mac

O que é LinuxDownload LinuxApostila LinuxEnviar notícia


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]”)


• Publicado por Augusto Campos em 2011-09-27

Comentários dos leitores

Os comentários são responsabilidade de seus autores, e não são analisados ou aprovados pelo BR-Linux. Leia os Termos de uso do BR-Linux.

    Fábio Lima (usuário não registrado) em 27/09/2011 às 3:32 pm

    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.

    Marcos (usuário não registrado) em 27/09/2011 às 4:00 pm

    Pelo jeito, essa falha de segurança é antiga, mas ninguém tinha descoberto e explorado. E aparentemente até agora não conseguiram encontrá-la.

    Dornival (usuário não registrado) em 27/09/2011 às 5:02 pm

    @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.

    Marcos (usuário não registrado) em 27/09/2011 às 5:32 pm

    @Dornival, se fosse só isso, seria apenas mudar a senha de todo mundo. Pra demorar tanto, é porque tem muito mais coisa aí.

    Junin (usuário não registrado) em 27/09/2011 às 6:06 pm

    @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

    afasffaf (usuário não registrado) em 27/09/2011 às 6:30 pm

    @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.

    Arielton (usuário não registrado) em 27/09/2011 às 7:05 pm

    @ Fabio Lima “Sistema 100% seguro não existe.”

    Mas existem sistemas “mais” seguros.

    Spif (usuário não registrado) em 27/09/2011 às 8:27 pm


    Pelo jeito, essa falha de segurança é antiga, mas ninguém tinha descoberto e explorado. E aparentemente até agora não conseguiram encontrá-la.

    Spif (usuário não registrado) em 27/09/2011 às 8:33 pm

    “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?

    Rodrigo Pinheiro Matias (usuário não registrado) em 27/09/2011 às 9:07 pm

    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;

    Dornival (usuário não registrado) em 28/09/2011 às 8:55 am

    @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.

    André Moraes (usuário não registrado) em 28/09/2011 às 9:14 am

    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.

    Spif (usuário não registrado) em 28/09/2011 às 1:19 pm

    @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.

Este post é antigo (2011-09-27) e foi arquivado. O envio de novos comentários a este post já expirou.