{"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\/de\/blog\/novosti-interneta\/universitet-minnesoty-otstranyon-ot-razrabotki-yadra-linux-za-otpravku-somnitelnyh-patchej","title":{"rendered":"Die University of Minnesota wurde von der Entwicklung des Linux-Kernels ausgeschlossen, nachdem fragw\u00fcrdige Patches eingereicht wurden.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Greg Kroah-Hartman, der f\u00fcr die Unterst\u00fctzung der stabilen Linux-Kernel-Reihe zust\u00e4ndig ist, hat entschieden, alle \u00c4nderungen, die von der Universit\u00e4t Minnesota stammen, f\u00fcr den Linux-Kernel abzulehnen und alle zuvor akzeptierten Patches zur\u00fcckzuziehen sowie sie erneut zu \u00fcberpr\u00fcfen. Grund f\u00fcr die Blockierung sind die Aktivit\u00e4ten einer Forschungsgruppe, die versucht hat, versteckte Schwachstellen im Code offener Projekte zu f\u00f6rdern. Diese Gruppe hat Patches eingereicht, die verschiedene Fehler beinhalteten, die Reaktionen der Community beobachtet und Wege untersucht, wie der \u00dcberpr\u00fcfungsprozess f\u00fcr \u00c4nderungen manipuliert werden kann. Greg ist der Meinung, dass derartige Experimente zur Einf\u00fchrung sch\u00e4dlicher \u00c4nderungen inakzeptabel und unethisch sind. <\/p>\n
Der Grund f\u00fcr die Blockierung war das Einreichen eines Patches durch die Mitglieder dieser Gruppe, der eine \u00dcberpr\u00fcfung des Zeigers hinzuf\u00fcgte, um m\u00f6gliche doppelte Aufrufe der Funktion \u201efree\u201c auszuschlie\u00dfen. Angesichts des Kontexts war die \u00dcberpr\u00fcfung jedoch sinnlos. Das Ziel des Patch-Einreichens war es herauszufinden, ob die fehlerhafte \u00c4nderung von den Kernel-Entwicklern \u00fcberpr\u00fcft werden w\u00fcrde. Neben dem genannten Patch gab es auch andere Versuche von Entwicklern der Universit\u00e4t Minnesota, fragw\u00fcrdige \u00c4nderungen am Kernel durchzuf\u00fchren, einschlie\u00dflich solcher, die mit dem Hinzuf\u00fcgen versteckter Schwachstellen in Verbindung stehen. <\/p>\n
Der einsendende Teilnehmer versuchte, sich damit zu rechtfertigen, dass er einen neuen statischen Analyse-Tool testet und die \u00c4nderung auf den Ergebnissen dieser \u00dcberpr\u00fcfung basiert. Greg wies jedoch darauf hin, dass die vorgeschlagenen Korrekturen nicht typisch f\u00fcr Fehler sind, die von statischen Analyse-Tools identifiziert werden, und dass alle eingereichten Patches tats\u00e4chlich keine Korrekturen vornehmen. Angesichts der Tatsache, dass die betreffende Gruppe von Forschern in der Vergangenheit bereits versucht hat, Patches mit versteckten Schwachstellen zu f\u00f6rdern, ist offensichtlich, dass sie ihre Experimente mit der Entwicklergemeinschaft des Kernsystems fortgesetzt haben. <\/p>\n
Es ist interessant, dass der fr\u00fchere Leiter der experimentierenden Gruppe an der legitimen Behebung von Schwachstellen beteiligt war, beispielsweise entdeckte er Informationslecks im USB-Stack (CVE-2016-4482) und in der Netzwerk-Subsystem (CVE-2016-4485). In der Studie \u00fcber versteckte Schwachstellen pr\u00e4sentiert die Gruppe von der Universit\u00e4t Minnesota das Beispiel der Schwachstelle CVE-2019-12819, die durch einen Patch verursacht wurde, der 2014 in den Kernel aufgenommen wurde. Der Patch f\u00fcgte in der Fehlerbehandlungsroutine im mdio_bus den Aufruf put_device hinzu, aber f\u00fcnf Jahre sp\u00e4ter stellte sich heraus, dass eine solche Manipulation zu einem Zugriff auf einen Speicherblock nach seiner Freigabe f\u00fchrte (\"use-after-free\"). <\/p>\n
Die Autoren der Studie behaupten zudem, dass sie in ihrer Arbeit Daten zu 138 Patches zusammengefasst haben, die Fehler einf\u00fchren und nicht mit den Teilnehmern der Studie in Verbindung stehen. Versuche, eigene fehlerhaften Patches einzureichen, beschr\u00e4nkten sich auf E-Mail-Korrespondenz, und solche \u00c4nderungen fanden keinen Eingang in Git (wenn der Maintainer nach dem Versand des Patches per E-Mail diesen als akzeptabel ansah, wurde er gebeten, die \u00c4nderung nicht aufzunehmen, da Fehler vorhanden waren, woraufhin ein korrekter Patch geschickt wurde). <\/p>\n
Erg\u00e4nzung 1: Angesichts der Aktivit\u00e4t des Autors des kritisierten Fixes sendet er schon lange Patches an verschiedene Kernuntereinheiten. So wurden k\u00fcrzlich in die Treiber radeon und nouveau \u00c4nderungen mit dem Aufruf pm_runtime_put_autosuspend(dev->dev) im Fehlermeldungsblock eingef\u00fcgt, die m\u00f6glicherweise zu einer Verwendung des Puffers nach der Freigabe des zugeh\u00f6rigen Speichers f\u00fchren. <\/p>\n
Erg\u00e4nzung 2: Greg hat 190 Commits zur\u00fcckgenommen, die mit den Adressen \"@umn.edu\" verbunden sind, und deren \u00dcberpr\u00fcfung erneut initiiert. Das Problem ist, dass Teilnehmer mit den Adressen \"@umn.edu\" nicht nur mit zweifelhaften Patches experimentiert haben, sondern auch echte Sicherheitsanf\u00e4lligkeiten behoben haben, und das Zur\u00fccknehmen der \u00c4nderungen k\u00f6nnte dazu f\u00fchren, dass zuvor behobene Sicherheitsprobleme zur\u00fcckkehren. Einige Maintainer haben die zur\u00fcckgenommenen \u00c4nderungen bereits \u00fcberpr\u00fcft und keine Probleme gefunden, aber einer der Maintainer wies darauf hin, dass in einem der ihm zugesandten Patches Fehler enthalten waren. \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"