In den letzten Tagen hat die Fall über die Maßnahmen einer Gruppe von Forschern von der University of Minnesota, da aus der Sicht vieler solche Aktionen im Zusammenhang mit der Einführung von Schwachstellen im Linux-Kernel keine Rechtfertigung haben.
Und obwohl eine Gruppe Forscher der Universität Minnesotein offenes Entschuldigungsschreiben zu veröffentlichen, deren Akzeptanz von Änderungen am Linux-Kernel, die von blockiert wurden Greg Kroah-Hartman enthüllte Details von Patches, die an Kernelentwickler gesendet wurden, und Korrespondenz mit Betreuern, die mit diesen Patches verbunden sind.
Es ist bemerkenswert, dass Alle Problem-Patches wurden abgelehnt Auf Initiative der Betreuer wurde keiner der Patches genehmigt. Diese Tatsache macht deutlich, warum Greg Kroah-Hartman so hart gehandelt hat, da unklar ist, was die Forscher getan hätten, wenn die Patches vom Betreuer genehmigt worden wären.
Im Rückblick, argumentierte, dass sie beabsichtigten, den Fehler zu melden und sie würden nicht zulassen, dass Patches zu Git gehen, aber es ist unklar, was sie tatsächlich tun würden oder wie weit sie gehen könnten.
Insgesamt wurden im August 2020 fünf Patches von den anonymen Adressen acostag.ubuntu@gmail.com und jameslouisebond@gmail.com (ein Brief von James Bond) gesendet: zwei korrekte und drei einschließlich versteckter Fehler, wodurch Bedingungen für das Auftreten von erstellt wurden Schwachstellen.
Jeder Patch enthielt nur 1 bis 4 Codezeilen. Die Hauptidee hinter den fehlerhaften Patches war, dass das Beheben eines Speicherverlusts eine Bedingung für eine doppelte freie Sicherheitsanfälligkeit schaffen kann.
Das Projekt zielt darauf ab, die Sicherheit des Patch-Prozesses in OSS zu verbessern. Im Rahmen des Projekts untersuchen wir potenzielle Probleme mit dem OSS-Patch-Prozess, einschließlich der Ursachen der Probleme und Vorschläge zu deren Behebung.
Tatsächlich zeigt diese Studie einige Probleme auf, aber ihr Ziel ist es, Anstrengungen zur Verbesserung der Situation zu fordern
Patch-Prozess, um mehr Arbeit zu motivieren, Techniken zum Testen und Überprüfen von Patches zu entwickeln und schließlich das Betriebssystem sicherer zu machen.Basierend auf diesen Patches fassen wir ihre Muster zusammen, untersuchen die spezifischen Gründe, warum Patches zur Fehlereinführung schwer zu finden sind (sowohl mit qualitativer als auch quantitativer Analyse), und geben vor allem Vorschläge zur Behebung des Problems.
Der erste problematische Patch hat den Speicherverlust behoben, indem kfree () aufgerufen wurde. vor dem Zurückgeben der Kontrolle im Fehlerfall, aber Erstellen von Bedingungen für den Zugriff auf den Speicherbereich nach dessen Freigabe (use-after-free).
Der angegebene Patch wurde vom Betreuer abgelehnt, der das Problem identifizierte und anzeigte, dass vor einem Jahr bereits jemand versucht hatte, eine ähnliche Änderung vorzuschlagen, und diese zunächst akzeptiert wurde, aber am selben Tag nach der Ermittlung der Schwachstellenbedingungen verworfen wurde.
Der zweite Patch enthielt auch Bedingungen für das Verschleißproblem nach der Veröffentlichung. Der angegebene Patch wurde vom Betreuer nicht akzeptiert, der den Patch aufgrund eines anderen Problems mit list_add_tail abgelehnt hat, jedoch nicht bemerkt hat, dass der Zeiger "chdev" in der Funktion put_device freigegeben werden kann, die beim Aufruf von dev_err (& als Nächstes verwendet wird) chdev -> dev ..). Der Patch wurde jedoch nicht akzeptiert, allerdings aus Gründen, die nichts mit der Sicherheitsanfälligkeit zu tun haben.
Seltsamerweise anfangs wurde angenommen, dass 4 von 5 Patches Probleme hatten, Aber die Forscher selbst haben einen Fehler gemacht und in einem problematischen Patch wurde ihrer Meinung nach die richtige Lösung vorgeschlagen, ohne die angeblichen Bedingungen für die Verwendung des Speichers nach dem Start.
In dieser Arbeit stellen wir das Konzept der «unreifen Verwundbarkeit» vor, bei der ein Zustand der Verwundbarkeit fehlt, der jedoch real werden kann, wenn der Zustand implizit vorliegt
eingeführt durch einen Patch für einen anderen Fehler.Wir entwickeln auch Tools, mit denen wir Codestellen finden können, die möglicherweise darunter leiden
der Fehlereinführungs-Patches und schlagen vor, was diese Fehlereinführungs-Patches möglicherweise schwer zu erkennen macht.Eine Woche später wurden Informationen an die Kernel-Entwickler gesendet, mit dem Vorschlag, die Möglichkeit der Förderung von Sicherheitslücken unter dem Deckmantel trivialer Korrekturen für Speicherlecks zu erörtern. Über frühere Versuche, böswillige Patches einzureichen, wurde jedoch nichts gesagt.
Der dritte Patch wurde vom Betreuer aufgrund eines anderen Fehlers ohne Sicherheitslücke ebenfalls abgelehnt (doppelte Anwendung in pdev).