{"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\/news\/universitet-minnesoty-otstranyon-ot-razrabotki-yadra-linux-za-otpravku-somnitelnyh-patchej","title":{"rendered":"Die Universit\u00e4t von Minnesota wurde von der Entwicklung des Linux-Kernels ausgeschlossen, da sie fragw\u00fcrdige Patches eingereicht hat.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Greg Kroah-Hartman, der f\u00fcr die Unterst\u00fctzung des stabilen Linux-Kernel-Zweigs verantwortlich ist, hat beschlossen, jegliche \u00c4nderungen, die von der University of Minnesota eingereicht werden, im Linux-Kernel zu verbieten und alle zuvor akzeptierten Patches zur\u00fcckzuziehen und erneut zu \u00fcberpr\u00fcfen. Der Grund f\u00fcr die Blockade war die T\u00e4tigkeit einer Forschungsgruppe, die die M\u00f6glichkeit der Einf\u00fchrung versteckter Schwachstellen in den Code offener Projekte untersuchte. Die genannte Gruppe hatte Patches eingereicht, die verschiedene Arten von Fehlern enthielten, beobachtete die Reaktion der Community und analysierte Wege, den \u00dcberpr\u00fcfungsprozess von \u00c4nderungen zu t\u00e4uschen. Greg ist der Meinung, dass solche Experimente zur Einf\u00fchrung sch\u00e4dlicher \u00c4nderungen inakzeptabel und unethisch sind. <\/p>\n
Der Anlass f\u00fcr die Blockierung war das Versenden eines Patches durch die Teilnehmer dieser Gruppe, der eine \u00dcberpr\u00fcfung des Zeigers hinzuf\u00fcgte, um m\u00f6gliche doppelte Aufrufe der Funktion \u201efree\u201c auszuschlie\u00dfen. Angesichts des Kontextes, in dem der Zeiger verwendet wurde, war die \u00dcberpr\u00fcfung jedoch sinnlos. Das Ziel des Versendens des Patches war es zu untersuchen, ob die fehlerhafte \u00c4nderung die \u00dcberpr\u00fcfung durch die Entwickler des Kernels bestehen w\u00fcrde. Neben dem genannten Patch gab es auch andere Versuche von Entwicklern der Universit\u00e4t Minnesota, fragw\u00fcrdige \u00c4nderungen am Kernel vorzunehmen, einschlie\u00dflich solcher, die mit dem Hinzuf\u00fcgen versteckter Sicherheitsanf\u00e4lligkeiten verbunden waren. <\/p>\n
Der Patch-Einreicher versuchte, sich damit zu rechtfertigen, dass er einen neuen statischen Analyzer teste und die \u00c4nderung auf der Grundlage der Ergebnisse aus diesem erstellt wurde. Doch Greg wies darauf hin, dass die vorgeschlagenen Korrekturen f\u00fcr Fehler, die von statischen Analyzern aufgedeckt werden, untypisch sind und dass alle eingereichten Patches \u00fcberhaupt nichts beheben. Angesichts der Tatsache, dass die betreffende Gruppe von Forschern in der Vergangenheit bereits versucht hatte, Korrekturen mit versteckten Schwachstellen voranzutreiben, ist offensichtlich, dass sie ihre Experimente mit der Community der Kernel-Entwickler fortgesetzt haben. <\/p>\n
Interessanterweise nahm der Leiter der experimentierenden Gruppe in der Vergangenheit an legitimen Korrekturen von Sicherheitsanf\u00e4lligkeiten teil, zum Beispiel entdeckte er Informationslecks im USB-Stack (CVE-2016-4482) und in der Netzwerksubsystem (CVE-2016-4485). In der Untersuchung von versteckten Sicherheitsanf\u00e4lligkeiten nennt die Gruppe der Universit\u00e4t Minnesota das Beispiel der Sicherheitsanf\u00e4lligkeit CVE-2019-12819, die durch einen Fix verursacht wurde, der 2014 in den Kernel \u00fcbernommen wurde. Der Fix f\u00fcgte im Fehlerbehandlungsblock im mdio_bus den Aufruf put_device hinzu, aber nach f\u00fcnf Jahren stellte sich heraus, dass eine solche Manipulation dazu f\u00fchrt, dass auf einen Speicherblock nach dessen Freigabe zugegriffen wird (\u201euse-after-free\u201c). <\/p>\n
Die Autoren der Untersuchung behaupten jedoch, dass sie in ihrer Arbeit Daten zu 138 Patches verallgemeinert haben, die Fehler einf\u00fchren und nicht mit den Teilnehmern der Studie verbunden sind. Versuche, eigene fehlerhafte Patches zu senden, 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 den Patch als in Ordnung empfand, wurde er gebeten, die \u00c4nderung nicht aufzunehmen, da ein Fehler vorlag, woraufhin ein korrekter Patch gesendet wurde). <\/p>\n
Erg\u00e4nzung 1: Anhand der Aktivit\u00e4t des Autors des kritisierten Fixes l\u00e4sst sich erkennen, dass dieser schon lange Patches an verschiedene Subsysteme des Kernels sendet. Zum Beispiel wurden k\u00fcrzlich \u00c4nderungen in den Treibern radeon und nouveau mit dem Aufruf pm_runtime_put_autosuspend(dev->dev) im Fehlerblock angenommen, was m\u00f6glicherweise zu einer Verwendung des Puffers nach der Freigabe des zugeh\u00f6rigen Speichers f\u00fchrt. <\/p>\n
Zusatz 2: Greg hat 190 Commits, die mit den Adressen \u201e@umn.edu\u201c verbunden sind, zur\u00fcckgesetzt und deren \u00dcberpr\u00fcfung erneut angesto\u00dfen. Das Problem ist, dass die Teilnehmer mit den Adressen \u201e@umn.edu\u201c nicht nur mit fragw\u00fcrdigen Patches experimentierten, sondern auch echte Sicherheitsanf\u00e4lligkeiten beheben. Das Zur\u00fccksetzen der \u00c4nderungen kann dazu f\u00fchren, dass zuvor behobene Sicherheitsprobleme zur\u00fcckkehren. Einige Maintainer haben bereits die zur\u00fcckgezogenen \u00c4nderungen \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":"