Daniel Stenberg, Autor eines Dienstprogramms zum Empfangen und Senden von Daten über das Netzwerk Curl, kritisierte den Einsatz von KI-Tools bei der Erstellung von Schwachstellenberichten. Solche Berichte enthalten detaillierte Informationen, sind in normaler Sprache verfasst und sehen hochwertig aus. Ohne eine sorgfältige Analyse der Realität können sie jedoch nur irreführend sein und echte Probleme durch hochwertig aussehenden Müllinhalt ersetzen.
Das Curl-Projekt zahlt Belohnungen für die Identifizierung neuer Schwachstellen und hat bereits 415 Berichte über potenzielle Probleme erhalten, von denen nur 64 als Schwachstellen und 77 als nicht sicherheitsrelevante Fehler bestätigt wurden. Somit enthielten 66 % aller Berichte keine nützlichen Informationen und raubten den Entwicklern nur Zeit, die sie für etwas Nützliches hätten verwenden können.
Entwickler sind gezwungen, viel Zeit damit zu verschwenden, nutzlose Berichte zu analysieren und die darin enthaltenen Informationen mehrmals zu überprüfen, da die äußere Qualität des Designs zusätzliches Vertrauen in die Informationen schafft und das Gefühl besteht, dass der Entwickler etwas falsch verstanden hat. Andererseits erfordert die Erstellung eines solchen Berichts nur minimalen Aufwand für den Antragsteller, der sich nicht die Mühe macht, nach einem echten Problem zu suchen, sondern einfach blind die von KI-Assistenten erhaltenen Daten kopiert und auf Glück im Kampf um eine Belohnung hofft.
Es werden zwei Beispiele für solche Müllberichte gegeben. Am Tag vor der geplanten Veröffentlichung von Informationen über die gefährliche Oktober-Schwachstelle (CVE-2023-38545) wurde über Hackerone eine Meldung verschickt, dass der Patch mit dem Fix öffentlich verfügbar geworden sei. Tatsächlich enthielt der Bericht eine Mischung aus Fakten zu ähnlichen Problemen und Ausschnitten detaillierter Informationen über frühere Schwachstellen, die von Googles KI-Assistent Bard zusammengestellt wurden. Dadurch wirkten die Informationen neu und relevant und hatten keinen Bezug zur Realität.
Beim zweiten Beispiel handelt es sich um eine am 28. Dezember eingegangene Nachricht über einen Pufferüberlauf im WebSocket-Handler, gesendet von einem Benutzer, der bereits über Hackerone verschiedene Projekte über Schwachstellen informiert hatte. Um das Problem zu reproduzieren, enthielt der Bericht allgemeine Hinweise zum Übergeben einer geänderten Anforderung mit einem Wert, der größer als die Größe des Puffers ist, der beim Kopieren mit strcpy verwendet wird. Der Bericht enthielt auch ein Beispiel für eine Korrektur (ein Beispiel für das Ersetzen von strcpy durch strncpy) und wies auf einen Link zur Codezeile „strcpy(keyval, randstr)“ hin, die nach Angaben des Antragstellers einen Fehler enthielt.
Der Entwickler hat alles dreimal überprüft und keine Probleme festgestellt, aber da der Bericht sicher geschrieben war und sogar eine Korrektur enthielt, hatte man das Gefühl, dass irgendwo etwas fehlte. Ein Versuch zu klären, wie es dem Forscher gelang, die explizite Größenprüfung vor dem strcpy-Aufruf zu umgehen und wie sich herausstellte, dass die Größe des Schlüsselval-Puffers kleiner als die Größe der gelesenen Daten war, führte zu detaillierten, aber nicht mit zusätzlichen Informationen versehenen Erklärungen Dabei ging es nur um die offensichtlichen, häufigen Ursachen von Pufferüberläufen, die nicht mit einem bestimmten Curl-Code zusammenhängen. Die Antworten erinnerten an die Kommunikation mit einem KI-Assistenten, und nachdem der Entwickler einen halben Tag mit sinnlosen Versuchen verbracht hatte, herauszufinden, wie sich das Problem genau manifestiert, war er schließlich davon überzeugt, dass tatsächlich keine Schwachstelle vorlag.
Source: opennet.ru