Neues GenAI-Software soll Open-Supply-Sicherheit erhöhen

Niederländische und iranische Sicherheitsforscher haben ein neues Software auf Foundation von generativer KI (GenAI) ins Leben gerufen, das Plattformen wie ChatGPT ermöglichen soll, Bugs in Code-Repositories zu erkennen und zu patchen.

Die Anwendung wurde getestet, indem GitHub nach einer bestimmten Schwachstelle durch Pfadüberquerung in Node.js-Projekten gescannt wurde, die seit 2010 besteht. Dabei wurden 1.756 anfällige Projekte identifiziert, von denen einige als „sehr einflussreich“ bezeichnet wurden. Bisher konnten 63 Projekte gepatcht werden.

Die in einem kürzlich veröffentlichten Artikel beschriebene Entwicklung weist jedoch auch auf eine gravierende Einschränkung bei der Verwendung von KI hin. Während das automatisierte Patchen durch ein großes Sprachmodell (LLM) die Skalierbarkeit erheblich verbessert, kann der Patch auch andere Fehler verursachen.

Außerdem könnte es schwierig sein, die betreffende Schwachstelle vollständig zu beseitigen, da einige beliebte große Sprachmodelle (LLMs) nach 15 Jahren davon infiziert sein könnten.

Der Grund: LLMs werden auf Open-Supply-Codebasen trainiert, in denen dieser Fehler verborgen ist.

Die Forscher fanden heraus, dass ein LLM, das mit einem anfälligen Quellcodemuster kontaminiert ist, diesen Code auch dann generiert, wenn es angewiesen wird, sicheren Code zu synthetisieren. Sie fordern daher, dass beliebte anfällige Codemuster nicht nur aus Open-Supply-Projekten und den Ressourcen von Entwicklern entfernt werden müssten, sondern auch aus LLMs.

Hacker platzieren seit Jahren bösartigen Code

Bedrohungsakteure pflanzen seit Jahren Schwachstellen in Open-Source-Repositories, um in Unternehmen einzudringen, die Open-Supply-Anwendungen einsetzen. Das Downside: Entwickler kopieren unwissentlich anfälligen Code aus Code-Sharing-Plattformen wie Stack Overflow und fügen ihn woanders ein, wodurch er in GitHub-Projekte gelangt.

„Angreifer müssen nur ein einziges anfälliges Codemuster kennen, um viele Projekte und deren nachgelagerte Abhängigkeiten erfolgreich angreifen zu können“, betonen die Forscher.

Die von ihnen entwickelte Lösung könnte die Entdeckung und Beseitigung von Open-Supply-Sicherheitslücken in großem Maßstab ermöglichen.

Dabei handelt es sich jedoch um kein Software, wo durch einmaliges Scannen alle Fehler behoben werden. Entwickler forken nämlich häufig Repositories, ohne etwas zu den ursprünglichen Projekten beizutragen. Das bedeutet, dass alle Repositories mit einem anfälligen Codeabschnitt gescannt und korrigiert werden müssen, damit eine Sicherheitslücke wirklich beseitigt wird.

Darüber hinaus verwendete das in dieser Studie untersuchte Muster für anfälligen Code den Pfadnamen der URL direkt und ohne spezielle Formatierung, wodurch eine leicht auszunutzen Schwachstelle entstand. Auf dieses Muster konzentriert sich das Software; andere Stellen, an denen der fehlerhafte Code platziert ist, werden nicht erkannt.

Die Forscher haben allerdings vor, das Software zu verbessern und zu erweitern, insbesondere durch die Integration anderer Muster für anfälligen Code und die Optimierung der Patch-Generierung.

Kritik an dem KI-Projekt

Robert Beggs, Leiter des kanadischen Incident-Response-Unternehmens DigitalDefence, steht dem Wert des Instruments in seiner derzeitigen Kind jedoch skeptisch gegenüber.

Die Idee eines automatisierten Instruments zum Scannen und Patchen von Schadcode gebe es schon seit einiger Zeit, betonte er.Allerdings werde in der Studie noch nicht geklärt, wer verantwortlich sei, wenn ein fehlerhafter Patch ein öffentliches Projekt beschädige. Beggs bezweifelt außerdem, dass ein Repository-Supervisor immer erkennen kann, dass ein KI-Software eine potenzielle Schwachstelle in eine Anwendung einfügen will.

Zudem ist unklar, inwieweit das Software nach der Behebung Exams durchführt, um sicherzustellen, dass der Patch keinen weiteren Schaden anrichtet. In dem Papier heißt es, dass letztendlich die Projektverantwortlichen dafür verantwortlich sind, dass der Patch korrekt ist. Der KI-Teil des Instruments erstellt einen Patch, berechnet einen CVSS-Rating und übermittelt einen Bericht an die Projektverantwortlichen.

„Ich persönlich würde das Software nicht verwenden, da es mit der Änderung von Quellcode zu tun hat“, erklärte Beggs. „Ich glaube nicht, dass künstliche Intelligenz bereits so weit ist, dass sie den Quellcode für eine große Anzahl von Anwendungen verwalten kann“, fügte er hinzu.

Er räumte jedoch ein, dass wissenschaftliche Artikel in der Regel nur einen ersten Ansatz für ein Downside darstellen.

Open-Supply-Entwickler können Teil des Issues sein

Im Laufe ihrer Arbeit entdeckten die Forscher auch eine beunruhigende Tatsache: Open-Supply-App-Entwickler ignorieren manchmal Warnungen, dass bestimmte Code-Schnipsel anfällig sind.

Der anfällige Code, den die Forscher in möglichst vielen GitHub-Projekten beheben wollten, stammte aus dem Jahr 2010 und ist in GitHub Gist zu finden, einem Dienst zum Austausch von Code-Schnipseln. Der Code erstellt einen statischen HTTP-Dateiserver für Node.js-Webanwendungen. „Trotz seiner Einfachheit und Beliebtheit scheinen viele Entwickler nicht zu wissen, dass dieses Codemuster anfällig für Pfadüberquerungsangriffe ist“, schreiben die Forscher.

Selbst diejenigen, die das Downside erkannt hatten, stießen auf Widerstand von anderen Entwicklern. Die Behauptung, dass der Code fehlerhaft sei, wurde mehrfach zurückgewiesen.

Unabhängig davon tauchte der Code-Schnipsel in einer gedruckten Model eines Dokuments auf, das 2015 von der Mozilla-Entwickler-Group erstellt und sieben Jahre später korrigiert wurde. Die anfällige Model wanderte jedoch Ende 2015 auch zu Stack Overflow. Obwohl der Ausschnitt mehrere Aktualisierungen erhielt, wurde die Schwachstelle nicht behoben. Tatsächlich warfare der Code-Ausschnitt zum Zeitpunkt der Veröffentlichung der aktuellen Forschungsergebnisse immer noch anfällig.

Das Gleiche geschah den Forschern zufolge 2016 bei einer anderen Stack-Overflow-Frage (mit über 88.000 Aufrufen), in der ein Entwickler vermutete, dass der Code eine Schwachstelle enthielt. Diese Individual konnte das Downside jedoch nicht überprüfen, sodass der Code erneut als sicher eingestuft wurde.

Die Forscher vermuten, dass das Missverständnis über die Schwere der Sicherheitslücke darauf zurückzuführen ist, dass Entwickler beim Testen des Codes in der Regel einen Webbrowser oder den Linux-Befehl „curl“ verwenden. Diese hätten das Downside verschleiert. Angreifer seien jedoch nicht an die Verwendung von Commonplace-Shoppers gebunden, so die Forscher.

Beunruhigend sei außerdem, dass „wir auch mehrere Node.js-Kurse gefunden haben, in denen dieser anfällige Code-Schnipsel zu Trainingszwecken verwendet wurde“, fügen die Forscher hinzu. (jm)

Lesetipp: 9 unverzichtbare Open Source Security Tools