Skip to content

Refactoring-Code in WebKit hat „Zombie“-Sicherheitsfehler wiederbelebt • The Register

Eine Sicherheitslücke in Apples Webbrowser Safari, die vor neun Jahren gepatcht wurde, wurde vor einigen Monaten erneut in freier Wildbahn ausgenutzt – ein perfektes Beispiel für eine „Zombie“-Schwachstelle.

Das ist ein Fehler, der gepatcht wurde, aber aus welchen Gründen auch immer auf aktuellen Systemen und Geräten immer wieder missbraucht werden kann – oder ein Fehler, der eng mit einem gepatchten zusammenhängt.

In einem Artikel in diesem Monat teilte Maddie Stone, eine Spitzenforscherin im Project Zero-Team von Google, Einzelheiten über eine Safari-Schwachstelle mit, von der die Leute im Januar dieses Jahres erkannten, dass sie in freier Wildbahn ausgenutzt wurde. Dieser Remote-Code-Execution-Fehler könnte beispielsweise von einer speziell gestalteten Website missbraucht werden, um Spyware auf dem Gerät einer anderen Person auszuführen, wenn sie in ihrem Browser angezeigt wird.

Der Fehler wurde als CVE-2022-22620 mit einem CVSS-Schweregrad von 8,8 von 10 verfolgt. Er wurde 2013 gepatcht und dann 2016 während einer Codeaktualisierung wieder eingeführt. Im Februar wurde es erneut von Apple in Safari- und iOS/iPadOS-Updates behoben.

„Fast die Hälfte des Jahres 2022 und es scheint, als würden wir einen ähnlichen Trend sehen“ bei solchen Zombie-Fehlern, schrieb Stone. „Angreifer brauchen keine neuartigen Fehler, um Benutzer mit Zero-Days effektiv auszunutzen, sondern können stattdessen Schwachstellen ausnutzen, die eng mit zuvor offengelegten verwandt sind.“

Letztes Jahr schrieb Stone, dass ein Viertel der im Jahr 2020 von Project Zero verfolgten Zero-Day-Schwachstellen in engem Zusammenhang mit Fehlern standen, die in der Vergangenheit öffentlich bekannt wurden. Typischerweise geschieht dies als Ergebnis eines unvollständigen Patches durch den Entwickler oder Hersteller – ein Software-Update behebt den zugrunde liegenden Fehler nicht vollständig, so dass er immer noch in irgendeiner Weise ausnutzbar bleibt.

Allerdings ist die Situation beim Safari-Loch etwas anders. In diesem Fall hat Apple die Lücke vollständig gepatcht, als die Schwachstelle im Jahr 2013 entdeckt wurde, aber „ihre Behebung wurde 2016 während des Refactorings rückgängig gemacht. Wir wissen nicht, wie lange ein Angreifer diese Schwachstelle in freier Wildbahn ausgenutzt hat, aber wir wissen, dass die Schwachstelle (wieder) fünf Jahre lang bestand: Dezember 2016 bis Januar 2022“, schrieb sie.

Das heißt, Ingenieure haben einige Teile ihres Quellcodes aufgeräumt und neu geordnet und als Ergebnis den ausnutzbaren Fehler versehentlich wieder eingeführt. Die vollständigen Details finden Sie in der technischen Analyse von Stone.

Die Schwachstelle im Jahr 2013 war ein use-after-free()-Fehler im History-API-Code in der Open-Source-WebKit-Engine von Safari. Die API bietet Zugriff auf den Verlauf der Browsersitzung und ermöglicht es dem Benutzer, den Verlauf zu ändern.

Der Fehler aus dem Jahr 2013 und der eng verwandte Fehler, der dieses Jahr ausgenutzt wurde, betreffen beide die History-API und könnten über einen speziell gestalteten Webinhalt missbraucht werden, wodurch Cyberkriminelle die Möglichkeit erhalten, auf den Geräten der Opfer willkürlichen Code auszuführen.

„Es ist derselbe Fehler, aber durch einen anderen Weg ausgelöst“, schrieb Stone. „Deshalb hat der Testfall von 2013 die Version von WebKit, die für CVE-2022-22620 hätte anfällig sein sollen, nicht zum Absturz gebracht.“

Sie stellte fest, dass die Entwickler im Jahr 2013 alle verschiedenen Pfade gepatcht haben, die die Schwachstelle ausgelöst haben, nicht nur denjenigen im Proof-of-Concept-Exploit-Code, der damals eingereicht wurde, um die Existenz eines Fehlers zu beweisen. Das im Dezember 2016 durchgeführte Refactoring hat die Schwachstelle jedoch wiederbelebt.

Laut Stone waren die Quellcode-Commits im Oktober und Dezember 2016 umfangreich. Der erste änderte 40 Dateien mit 900 Hinzufügungen und 1.225 Löschungen, während der zweite Commit 95 Dateien mit 1.336 Hinzufügungen und 1.325 Löschungen änderte.

Sie zählte das Refactoring zu den wichtigsten Herausforderungen, denen sich Entwickler gegenübersehen – neben anderen wie Legacy-Code, kurzen Bearbeitungszeiten für Reviewer und Legacy-Code. Und sie argumentierte, dass Entwickler und Sicherheitsteams Zeit brauchen, um Patches zu überprüfen – insbesondere solche, die aus Sicherheitsgründen vorgenommen wurden. Darüber hinaus wird die Belohnung dieser Bemühungen „auf lange Sicht Ressourcen des Anbieters sparen“, schrieb Stone.

„In diesem Fall musste neun Jahre, nachdem eine Schwachstelle ursprünglich gesichtet, gepatcht, getestet und veröffentlicht wurde, der gesamte Prozess erneut dupliziert werden, diesmal jedoch unter dem Druck der Ausbeutung in der Wildnis.“

Apple behebt das Problem, ist aber nicht allein

Im Februar veröffentlichte Apple Patches für die Schwachstelle CVE-2022-22620.

Stone bemerkte, dass der Fehler in Apple Safari nicht die einzige Zombie-Vuln-Situation in diesem Jahr war. Im Jahr 2022 wurde Project Zero auch in freier Wildbahn Zero-Days gesehen, bei denen es sich um Varianten von zuvor offenbarten Fehlern in Chromium, Windows, Pixel-Geräten und iOS handelt.

Im Jahr 2020 stellte die Gruppe fest, dass sechs von 24 Zero-Day-Exploits in engem Zusammenhang mit Schwachstellen standen, die zuvor in Windows, Firefox, Chrome und Safari offengelegt worden waren.

„Einige dieser 0-Day-Exploits mussten nur ein oder zwei Codezeilen ändern, um einen neuen funktionierenden 0-Day-Exploit zu haben“, schrieb Stone letztes Jahr und fügte hinzu, dass er 2020 „[One] von allen 4 erkannten 0-Day-Exploits hätte möglicherweise vermieden werden können, wenn eine gründlichere Untersuchung und Patching-Bemühungen untersucht worden wären. In der gesamten Branche ermöglichen unvollständige Patches – Patches, die die Grundursache einer Schwachstelle nicht korrekt und umfassend beheben – Angreifern, 0-Days mit weniger Aufwand gegen Benutzer einzusetzen.“

John Bambenek, leitender Forscher beim Cybersicherheitsanbieter Netenrich, sagte Das Register dass Zombie-0-Tage typischerweise aus unvollständigem Patchen resultieren. Softwarefirmen müssen die Sicherheit ihrer Produkte belohnen und wertschätzen und Entwicklern und Sicherheitsexperten Zeit geben, Commits auf Robustheit zu prüfen.

„Vor allem Unternehmen, die Wert auf Features legen, werden dieses Problem immer wieder sehen“, sagte Bambenek. „Dieses Problem tritt generell bei der Softwareentwicklung auf. Menschen sind Gewohnheitstiere, daher führen die Denk- und Handlungsmuster, die zu Schwachstellen geführt haben, auch zu deren Wiedereinführung.“ ®

Leave a Reply

Your email address will not be published.