Início » Aplicativos e Software » Equipe do Linux rejeita desculpas de pesquisadores por código malicioso

Equipe do Linux rejeita desculpas de pesquisadores por código malicioso

Pesquisadores da Universidade de Minnesota pediram desculpas por códigos com falhas enviados ao kernel, mas não convenceram

Emerson Alecrim Por

Na semana passada, pesquisadores da Universidade de Minnesota (UMN) foram banidos pelos mantenedores do Linux por enviarem ao projeto códigos maliciosos como parte de um estudo. No último sábado (24), eles divulgaram uma carta aberta à comunidade em que pedem desculpas pelo o que fizeram. De nada adiantou: o texto com quase 800 palavras teve recepção fria.

Programando no Linux (imagem ilustrativa: Sárfi Benjámin/Pixabay)

Programando no Linux (imagem ilustrativa: Sárfi Benjámin/Pixabay)

Correções com falhas

Basicamente, o estudo em questão teve como objetivo demonstrar que projetos de código-fonte aberto podem ser suscetíveis ao recebimento de contribuições que introduzem vulnerabilidades conhecidas no software.

Para isso, os pesquisadores adotaram uma tática que consistiu em encontrar três falhas de baixa prioridade no kernel, corrigi-las e submetê-las aos mantenedores do Linux. Porém, cada correção tinha uma “vulnerabilidade imatura”, isto é, uma falha que só causa problemas na presença de um recurso adicional, como uma chamada para uma biblioteca.

As correções foram submetidas aos mantenedores, sem os recursos adicionais, com o intuito de checar se eles detectariam as vulnerabilidades inseridas intencionalmente nelas, o que não aconteceu.

Tão logo tiveram retorno sobre as correções submetidas, os pesquisadores apontaram as falhas introduzidas e ofereceram patches sem brechas. Apesar disso, os mantenedores não gostaram nem um pouco de saber que estavam sendo testados dessa forma e sem aviso prévio.

Como reação, Greg Kroah-Hartman, um dos principais mantenedores do Linux depois de Linus Torvalds, decidiu rejeitar por padrão todas as contribuições submetidas por desenvolvedores com e-mail @umn.edu, com exceção para aquelas comprovadamente legítimas e que puderem ser verificadas. Mas, com relação a estas, Kroah-Hartman disse: “sério, por que perder seu tempo fazendo essa trabalho extra?”

O pedido de desculpas

Na carta de desculpas, Kangjie Lu, Qiushi Wu e Aditya Pakki, os três integrantes da UMN que protagonizam essa história, explicam que não avisaram os mantenedores sobre o estudo porque, do contrário, em vez de seguir a rotina padrão de atividades, eles estariam focados em procurar as falhas inseridas nas correções — estas, aliás, foram chamadas pelos pesquisadores de “commits hipócritas”.

Além disso, eles ressaltam que o Linux não ficou vulnerável porque as três correções em questão tiveram sua implementação interrompida e que as conclusões do grupo foram relatadas à comunidade antes da publicação da pesquisa.

O trio também argumenta que as 190 correções enviadas por membros da UMN que foram revertidas ou reavaliadas pelos mantenedores — outra “punição” aplicada — são legítimas, ou seja, não têm ligação com o estudo.

Queremos apenas que vocês saibam que nós nunca prejudicaríamos intencionalmente a comunidade do kernel Linux e nunca introduziríamos brechas de segurança. Nosso trabalho foi conduzido com a melhor das intenções e esteve focado em encontrar e corrigir falhas.

Kangjie Lu, Qiushi Wu e Aditya Pakki

Carta não convenceu

A carta foi enviada no último sábado (24). No dia seguinte, Greg Kroah-Hartman confirmou o recebimento, mas não se mostrou sensibilizado com os argumentos.

Em resposta, ele avisou que, na sexta-feira (23), a Linux Foundation enviou uma carta à Universidade de Minnesota descrevendo as ações que a instituição precisa seguir para reconquistar a confiança da comunidade do kernel. “Enquanto essas ações não forem executadas, não teremos nada mais a discutir sobre o assunto”, finalizou Kroah-Hartman.

As exigências da Linux Foundation enviadas à UMN ainda não foram reveladas. De todo modo, a universidade já havia anunciado a decisão de suspender essa linha de pesquisa e tomar medidas corretivas.

Com informações: Ars Technica.

Comentários da Comunidade

Participe da discussão
14 usuários participando

Os mais notáveis

Comentários com a maior pontuação

Sérgio (@trovalds)

Ego ferido de quem? Tu submete código propositalmente falho a um repositório só pra testar se a equipe que revisa está atenta é aceitável?

imhotep (@imhotep)

Só acusaram o golpe.
Os defensores do Linux adoram dizer que o sistema é seguro porque vc pode auditar o código (como se todo mundo tivesse competência para isso). Esperava-se que no caso em destaque isso fosse confirmado.

E não duvido que a reação tenha sido essa só porque os alunos (e o professor) são asiáticos.

Sérgio (@trovalds)

O código foi descartado como falho antes mesmo de ser submetido a candidato pra se tornar parte do kernel. E, além disso, o código era vulnerável propositalmente. E mesmo o código que está em produção ainda fica sendo revisado e estudado por “caçadores de vulnerabilidades”.

Não, a medida não foi desproporcional. A medida foi um alerta pra quem quer ficar brincando com coisa séria.

Uma coisa é surgir uma vulnerabilidade porque em “determinada condição” você pode explorá-la. Isso pode ser inerente à linguagem, ao conjunto de outras bibliotecas, etc. Outra coisa é você querer submeter um código que é descaradamente vulnerável “a título de pesquisa e desenvolvimento”.

A parte do “asiáticos” nem vou comentar porque não vale a pena.

² (@centauro)

O problema não foi a pesquisa em si, já que pesquisa e testes sobre vulnerabilidade em software não é algo fora do normal. O problema foi o fato deles terem feito isso sem ter avisado ninguém entre os responsáveis pelo kernel (principalmente para discutir responsabilidades e limites no âmbito da pesquisa) de que estavam fazendo esse tipo de teste.
Ou seja, algo bem parecido com um ataque malicioso.

Nos comentários lá do Ars tem uma analogia que eu achei interessante.
O que os pesquisadores fizeram seria que nem você ir numa loja, furtar um produto e alegar que “só estava checando o sistema de segurança de loja” caso seja pego.

Fábio Emilio Costa (@Fabio_Emilio_Costa)

No passado pesquisas similares foram feitas em toda uma série de projetos opensource. Em todos eles, uma parte da alta hierarquia do projeto estava ciente da pesquisa, o que é parte do procedimentos quando rola pentests. Mesmo que não se alerte o quando ou como, se alerta para que não ocorra danos colaterais. O que houve foi uma falta de ética dos pesquisadores de não informarem os principais nomes da comunidade que isso seria feito com o objetivo de pesquisa. Caso um código malicioso passasse, seria responsabilidade de quem? Provavelmente esses pesquisadores se isentariam usando a cartada da pesquisa .

Foi antiético e a medida do Greg foi correta.

E sim, o Linux pode ser auditado pelo código fonte, e você está certo por entender que não é todo mundo que tem tal competência, mas essa ação não remove a confiança do código do Linux, e sim coloca um grande ponto de interrogação na ética da Universidade de Minessota, de onde os “pesquisadores” são.

Sérgio (@trovalds)

O que, tempo de não ver ninguém corroborando com o seu argumento (ruim) de que os mantenedores do kernel são xenofóbicos? Ou ficou “xatiado” que mais gente concordou com a decisão dos mantenedores e você acabou sendo o “do contra”? É só melhorar os seus argumentos. Ou não participar da discussão.

R F (@R_F)

É por isso que comunidades sérias possuem uma canal fechado para envio de falhas de segurança.

Submeter uma código malicioso vai claramente contra o propósito desse canal, que é reduzir a difusão do código. Porque não são apenas developers que estão de olho no código, tem muito cracker e black hat também. Principalmente contratados por governos com interesse em invasão e sabotagem.

Breno (@bbcbreno)

Isso pra mim cheira a malandragem e n pesquisa.

Claro q para testar uma equipe o correto é que eles n saibam q estão sendo testados. Porém, neste cenário, alguém do outro lado tem que saber que um teste tá pra acontecer, até mesmo pra saber se aprova tal teste.

Pra mim só tem 2 possibilidades:

Esse pessoal foi inocente demais Esse pessoal queria explorar futuras vulnerabilidades

Tô mais pendendo pra 2a opção.