Cyberbedrohungen
Irren ist menschlich, R ist Statistik
Die Open Source-Programmiersprache R für die Analyse statistischer Daten hat eine Schwachstelle, die Ausführung von Code ermöglicht – wieder eine Lücke in der Software-Lieferkette, die uns zu denken geben sollte. Wie kann man schnell handeln?
Save to Folio
Kürzlich wurde in der De-Serialisierung der Open Source Programmiersprache R eine Schwachstelle entdeckt, die die Ausführung von Code ermöglicht, wenn sie auf speziell gestaltete Inhalte trifft. Die Schwachstelle hat weitreichende Auswirkungen, da R in kritischen Bereichen weit verbreitet ist und eine große Anzahl von Paketen in Datenanalyseumgebungen ohne ausreichende Kontrollen eingesetzt wird.
Aber warum sollte uns das interessieren? Zum einen handelt es sich wieder um eine Sicherheitslücke in der Software-Lieferkette, die uns zu denken geben sollte. Denn, sind Sie sicher, dass hat es nicht jemand geschafft, irgendwo in der Datenverarbeitungskette kompromittierte Inhalte (Pakete und/oder Daten) einzuschleusen?
Zum anderen wurde R für die statistische Analyse großer Datensätze - d.h. Millionen von Zeilen - entwickelt. Im Laufe der Jahre ist das R-Ökosystem dahingehend optimiert worden, diese Datensätze mit sehr hoher Geschwindigkeit zu verarbeiten. Es kamen Tools unter anderem für Data Mining, Datenbereinigung und KI-Funktionen hinzu. Wer sich heutzutage in einer wissenschaftlichen Arbeit eine Analyse einer großen Menge statistischer Daten oder eine Visualisierung dieser Daten ansieht, kann mit hoher Wahrscheinlichkeit davon ausgehen, dass R zur Erstellung der Analyse und der Grafiken verwendet wurde.
R im Hintergrund
Aber die Leistungsfähigkeit von R geht über seine sichtbare Seite hinaus. Dank seines umfangreichen Paket-Ökosystems und jahrelanger Optimierung kann R große Datensätze mit beeindruckender Geschwindigkeit verarbeiten. Dabei geht es nicht nur um die Berechnung von Zahlen - das Paket-Ökosystem bietet Statistikern und Datenwissenschaftlern auch eine Fülle von bewährten und optimierten statistischen Methoden, maschinelles Lernen und KI-Modelle, die sie sofort einsetzen können.
R wird in großem Umfang im Hintergrund verwendet, um Daten für viele Anwendungen (vor-) zu verarbeiten (zu trainieren), z. B. für die Vorhersage von Ressourcen (z. B. Windenergie) oder die statistische Analyse von Sensordaten für die vorausschauende Wartung, einschließlich des aktuellen Medienaushängeschilds „künstliche Intelligenz“. Auch wenn R nicht so bekannt ist wie andere Frameworks (z. B. NumPy von Python), ist es doch Teil vieler Daten-Pipelines, die im Hintergrund Daten verarbeiten, entweder für den direkten Verbrauch oder als Grundlage für das Training von KI-Modellen.
Schwachstelle bei der De-Serialisierung
Die Schwachstelle liegt in der Serialisierungsbibliothek von R - genauer gesagt in der De-Serialisierung. (De-)Serialisierung ist die Umwandlung von In-Memory-Strukturen in Daten, die geschrieben (Serialisierung) oder gelesen (De-Serialisierung) werden können, z. B. von einer Festplatte. Die Schwachstelle (CVE-2024-27322) in der De-Serialisierung von R ermöglicht die Ausführung von Code, wenn sie auf speziell gestaltete Inhalte trifft. Die schlechte Nachricht ist, dass kein menschliches Eingreifen erforderlich ist, um diese Sicherheitslücke auszunutzen. Es genügt, eine anfällige R-Instanz dazu zu bringen, die kompromittierten Daten zu lesen, um die Sicherheitslücke und die Codeausführung auszulösen.
Dies ist ein weiterer Fall von Sicherheitslücken in der Lieferkette. Im Kielwasser von Log4J vor einiger Zeit und XZ in jüngerer Zeit haben die potenziellen Auswirkungen der Verwendung anfälliger Softwarekomponenten, einschließlich Technologien (z. B. SBOMs), und der Umgang mit ihnen einige Aufmerksamkeit erhalten. Diese Schwachstellen sind nur ein spezifisches Beispiel für die Sicherheit der Lieferkette im Zusammenhang mit digitalen Artefakten.
Überprüfen Sie Code und Daten!
Wenn Sie R selbst in einer Datenverarbeitungskette verwenden oder Daten Dritter zum Trainieren von ML- oder KI-Modellen nutzen, können Sie sicher sagen, dass diese nicht kompromittiert sind? Das heißt, hat es jemand geschafft, irgendwo in der Datenverarbeitungskette kompromittierte R-Inhalte (Pakete und Daten) bereitzustellen?
Was die Beantwortung dieser Frage so schwierig macht, ist die Tatsache, dass jedes Paket, auf das sich Ihre R-Pipeline verlässt, jedes Stück serialisierter Daten, von denen diese Pakete abhängen, und alle serialisierten Daten, die Sie selbst einlesen, die Schwachstelle auslösen können. Und das hebt diese Sicherheitslücke auf eine ganz neue Ebene. Das Aufspüren von Schwachstellen in anfälligen Paketen ist etwas, das mit SBOMs erreicht werden kann. Aber in diesem Fall können auch „tote“ Daten die Sicherheitslücke auslösen!
In dieser Hinsicht ist diese R-Schwachstelle eine Art Aushängeschild für die Sicherheit der Lieferkette in Bezug auf digitale Artefakte. Und diese digitalen Artefakte umfassen nicht nur ausführbaren Code wie Pakete, sondern eben auch „tote“ Daten!
Fazit
Angesichts aktueller und künftiger Gesetze und Vorschriften wie NIS2, DORA oder CRA, die Cyber-Resilienz und Lieferkettensicherheit vorschreiben, zeigt die R-Schwachstelle, dass es an der Zeit ist zu handeln! Sie müssen in der Lage sein, die Frage, ob Sie potenziell betroffen sind, schnell zu beantworten (entweder in Ihren eigenen Datenverarbeitungspipelines und durch Nachfragen bei Ihren Datenanbietern oder, noch besser, indem Sie sie zwingen, aktuelle SBOMs bereitzustellen) und dann Prozesse einzurichten, um entweder den Patch so schnell wie möglich anzuwenden oder andere Maßnahmen wie Sandboxing zu ergreifen.
Sie müssen aber auch die toten Daten, die Sie in eine Datenverarbeitungs-Pipeline einspeisen, überprüfen und nachverfolgen, denn jede serialisierte R-Datei, die in die Pipeline eingespeist wird, könnte die Sicherheitslücke auslösen.
Daten (im Gegensatz zu Code) galten schon immer als „standardmäßig sicher“. Die R-Sicherheitslücke zeigt deutlich, dass dies nicht der Fall ist. Sogar „nur“ Daten und wie sie erstellt wurden, müssen nachverfolgt werden.
Da Daten das „neue Öl“ sind, insbesondere im Zusammenhang mit KI, ist oder wird diese Aufgabe sehr groß sein. Wenn Sie Daten als Eintrittspunkt in Ihre Lieferkette ignorieren, könnte das ein Rezept für eine Katastrophe sein. Daher müssen Sie über Prozesse und Tools verfügen, um sowohl Code- als auch Datenabhängigkeiten zu verfolgen.