{"id":99982,"date":"2021-04-21T22:23:44","date_gmt":"2021-04-21T20:23:44","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/universitet-minnesoty-otstranyon-ot-razrabotki-yadra-linux-za-otpravku-somnitelnyh-patchej"},"modified":"2021-04-21T22:23:44","modified_gmt":"2021-04-21T20:23:44","slug":"universitet-minnesoty-otstranyon-ot-razrabotki-yadra-linux-za-otpravku-somnitelnyh-patchej","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/news\/universitet-minnesoty-otstranyon-ot-razrabotki-yadra-linux-za-otpravku-somnitelnyh-patchej","title":{"rendered":"A Universidade de Minnesota foi banida do desenvolvimento do n\u00facleo do Linux por enviar patches duvidosos.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Greg Kroah-Hartman, respons\u00e1vel pela manuten\u00e7\u00e3o da ramifica\u00e7\u00e3o est\u00e1vel do kernel Linux, decidiu proibir a aceita\u00e7\u00e3o de quaisquer mudan\u00e7as no kernel Linux provenientes da Universidade de Minnesota, bem como reverter todos os patches anteriormente aceitos e revis\u00e1-los novamente. A raz\u00e3o para o bloqueio foi a atividade de um grupo de pesquisa que estudava a possibilidade de introduzir vulnerabilidades ocultas no c\u00f3digo de projetos abertos. O grupo mencionado enviou patches que inclu\u00edam v\u00e1rios tipos de erros, observou a rea\u00e7\u00e3o da comunidade e explorou maneiras de enganchar o processo de revis\u00e3o das mudan\u00e7as. Na opini\u00e3o de Greg, a realiza\u00e7\u00e3o de tais experimentos para injetar mudan\u00e7as maliciosas \u00e9 inaceit\u00e1vel e anti\u00e9tica. <\/p>\n
A raz\u00e3o da bloqueio foi o envio, pelos membros deste grupo, de um patch que adicionava uma verifica\u00e7\u00e3o de ponteiro para evitar uma poss\u00edvel chamada dupla da fun\u00e7\u00e3o \u201cfree\u201d. Considerando o contexto de uso do ponteiro, a verifica\u00e7\u00e3o era sem sentido. O objetivo do envio do patch era investigar se a altera\u00e7\u00e3o err\u00f4nea passaria pela revis\u00e3o dos desenvolvedores do n\u00facleo. Al\u00e9m do patch mencionado, surgiram outras tentativas dos desenvolvedores da Universidade de Minnesota de introduzir mudan\u00e7as duvidosas no n\u00facleo, incluindo aquelas relacionadas \u00e0 adi\u00e7\u00e3o de vulnerabilidades ocultas. <\/p>\n
O participante que enviou os patches tentou se justificar alegando que estava testando um novo analisador est\u00e1tico e que a modifica\u00e7\u00e3o foi preparada com base nos resultados da verifica\u00e7\u00e3o nele. Mas Greg chamou a aten\u00e7\u00e3o para o fato de que as corre\u00e7\u00f5es propostas n\u00e3o eram caracter\u00edsticas dos erros identificados por analisadores est\u00e1ticos, e todos os patches enviados n\u00e3o corrigiam nada. Considerando que o grupo de pesquisadores em quest\u00e3o j\u00e1 havia tentado no passado promover corre\u00e7\u00f5es com vulnerabilidades ocultas, \u00e9 evidente que eles continuaram seus experimentos em rela\u00e7\u00e3o \u00e0 comunidade de desenvolvedores do kernel. <\/p>\n
Curiosamente, no passado, o l\u00edder do grupo que conduz experimentos participou de corre\u00e7\u00f5es leg\u00edtimas de vulnerabilidades, por exemplo, identificou vazamentos de informa\u00e7\u00f5es na pilha USB (CVE-2016-4482) e na subsistema de rede (CVE-2016-4485). No estudo sobre a promo\u00e7\u00e3o oculta de vulnerabilidades, o grupo da Universidade de Minnesota cita um exemplo da vulnerabilidade CVE-2019-12819, que foi causada por uma corre\u00e7\u00e3o adotada no n\u00facleo em 2014. A corre\u00e7\u00e3o adicionava uma chamada put_device no bloco de tratamento de erros em mdio_bus, mas depois de cinco anos, revelou-se que tal manipula\u00e7\u00e3o leva ao acesso a um bloco de mem\u00f3ria ap\u00f3s sua libera\u00e7\u00e3o (\u201cuse-after-free\u201d). <\/p>\n
No entanto, os autores do estudo afirmam que, em seu trabalho, generalizaram dados sobre 138 patches que introduzem erros e n\u00e3o est\u00e3o relacionados aos participantes da pesquisa. As tentativas de enviar patches com erros eram limitadas a trocas de e-mail, e essas altera\u00e7\u00f5es n\u00e3o foram inclu\u00eddas no Git (se, ap\u00f3s o envio do patch por e-mail, o mantenedor considerasse o patch normal, ele era solicitado a n\u00e3o incluir a altera\u00e7\u00e3o, pois havia um erro, ap\u00f3s o que um patch correto era enviado). <\/p>\n
Adendo 1: Judging pela atividade do autor da corre\u00e7\u00e3o criticada, ele j\u00e1 h\u00e1 bastante tempo envia patches para diversos subsistemas do kernel. Por exemplo, mudan\u00e7as com a chamada pm_runtime_put_autosuspend(dev->dev) foram recentemente aceitas nos drivers radeon e nouveau no bloco de erro, o que pode levar ao uso de um buffer ap\u00f3s a libera\u00e7\u00e3o da mem\u00f3ria associada. <\/p>\n
Adendo 2: Greg reverteu 190 commits relacionados a endere\u00e7os \u201c@umn.edu\u201d e iniciou sua reavalia\u00e7\u00e3o. O problema \u00e9 que os participantes com endere\u00e7os \u201c@umn.edu\u201d n\u00e3o apenas experimentaram a promo\u00e7\u00e3o de patches duvidosos, mas tamb\u00e9m corrigiram vulnerabilidades reais, e a revers\u00e3o dessas mudan\u00e7as pode levar ao retorno de problemas de seguran\u00e7a anteriormente corrigidos. Alguns mantenedores j\u00e1 revisaram as altera\u00e7\u00f5es revertidas e n\u00e3o encontraram problemas, mas um dos mantenedores apontou que um dos patches enviados a ele continha erros. \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"