Greg Kroah-Hartman, verantwortlich für die Wartung des stabilen Zweigs des Linux-Kernels, beschloss, die Annahme von Änderungen der University of Minnesota am Linux-Kernel zu verbieten und außerdem alle zuvor akzeptierten Patches zurückzusetzen und sie erneut zu überprüfen. Grund für die Sperrung waren die Aktivitäten einer Forschungsgruppe, die die Möglichkeit untersuchte, versteckte Schwachstellen in den Code von Open-Source-Projekten einzuschleusen. Diese Gruppe reichte Patches ein, die verschiedene Arten von Fehlern enthielten, beobachtete die Reaktion der Community und untersuchte Möglichkeiten, den Überprüfungsprozess für Änderungen zu betrügen. Laut Greg ist die Durchführung solcher Experimente zur Einführung böswilliger Änderungen inakzeptabel und unethisch.
Der Grund für die Sperrung war, dass die Mitglieder dieser Gruppe einen Patch verschickten, der eine Zeigerprüfung hinzufügte, um den möglichen Doppelaufruf der „freien“ Funktion zu verhindern. Angesichts des Kontexts der Verwendung des Zeigers war die Überprüfung sinnlos. Der Zweck der Übermittlung des Patches bestand darin, zu sehen, ob die fehlerhafte Änderung die Prüfung durch die Kernel-Entwickler bestehen würde. Zusätzlich zu diesem Patch sind weitere Versuche von Entwicklern der University of Minnesota aufgetaucht, zweifelhafte Änderungen am Kernel vorzunehmen, darunter auch solche, die mit dem Hinzufügen versteckter Schwachstellen zusammenhängen.
Der Teilnehmer, der die Patches verschickte, versuchte sich damit zu rechtfertigen, dass er einen neuen statischen Analysator teste und die Änderung auf der Grundlage der Testergebnisse darin vorbereitet wurde. Greg machte jedoch darauf aufmerksam, dass die vorgeschlagenen Korrekturen nicht typisch für Fehler sind, die von statischen Analysegeräten erkannt werden, und dass alle gesendeten Patches überhaupt nichts beheben. Wenn man bedenkt, dass die betreffende Forschungsgruppe bereits in der Vergangenheit versucht hatte, Patches für versteckte Schwachstellen zu veröffentlichen, ist es offensichtlich, dass sie ihre Experimente mit der Kernel-Entwickler-Community fortsetzten.
Interessanterweise war der Leiter der Gruppe, die die Experimente durchführte, in der Vergangenheit an der legitimen Behebung von Schwachstellen beteiligt, beispielsweise an der Identifizierung von Informationslecks im USB-Stack (CVE-2016-4482) und im Netzwerksubsystem (CVE-2016-4485). . In einer Studie zur Verbreitung von Stealth-Schwachstellen führt ein Team der University of Minnesota als Beispiel CVE-2019-12819 an, eine Schwachstelle, die durch einen 2014 veröffentlichten Kernel-Patch verursacht wurde. Der Fix fügte einen Aufruf von put_device zum Fehlerbehandlungsblock in mdio_bus hinzu, aber fünf Jahre später stellte sich heraus, dass eine solche Manipulation zum Zugriff auf den Speicherblock führt, nachdem dieser freigegeben wurde („use-after-free“).
Gleichzeitig geben die Autoren der Studie an, in ihrer Arbeit Daten zu 138 Patches zusammengefasst zu haben, die Fehler verursachten und keinen Bezug zu den Studienteilnehmern hatten. Versuche, eigene Patches mit Fehlern zu senden, beschränkten sich auf E-Mail-Korrespondenz, und solche Änderungen gelangten nicht in Git (wenn der Betreuer nach dem Versenden des Patches per E-Mail den Patch als normal ansah, wurde er gebeten, die Änderung nicht aufzunehmen, da er dort enthalten war). war ein Fehler, woraufhin sie den richtigen Patch schickten).
Ergänzung 1: Der Aktivität des Autors des kritisierten Patches nach zu urteilen, sendet er seit langem Patches an verschiedene Kernel-Subsysteme. Beispielsweise haben die Radeon- und Nouveau-Treiber kürzlich Änderungen mit einem Aufruf von pm_runtime_put_autosuspend(dev->dev) in einem Fehlerblock übernommen, was möglicherweise dazu führte, dass der Puffer verwendet wurde, nachdem der damit verbundene Speicher freigegeben wurde.
Nachtrag 2: Greg hat 190 mit „@umn.edu“ verknüpfte Commits zurückgesetzt und eine erneute Überprüfung derselben eingeleitet. Das Problem besteht darin, dass Mitglieder mit „@umn.edu“-Adressen nicht nur mit der Verbreitung fragwürdiger Patches experimentiert haben, sondern auch echte Schwachstellen gepatcht haben und das Zurücksetzen von Änderungen dazu führen könnte, dass zuvor gepatchte Sicherheitsprobleme erneut auftreten. Einige Betreuer haben die rückgängig gemachten Änderungen bereits erneut überprüft und keine Probleme festgestellt, aber einer der Betreuer gab an, dass einer der an ihn gesendeten Patches Fehler aufwies.
Source: opennet.ru