Daniel Stenberg, der Autor des Tools zur Übertragung und zum Empfang von Daten über das Netzwerk curl, hat die Verwendung von KI-Tools zur Erstellung von Berichten über Sicherheitsanfälligkeiten kritisiert. Solche Berichte enthalten detaillierte Informationen, sind in normaler Sprache verfasst und wirken qualitativ hochwertig. Ohne eine gründliche Analyse können sie jedoch irreführend sein, indem sie reale Probleme durch qualitativ ansprechend aussehenden, sinnlosen Inhalt ersetzen.
Das Curl-Projekt vergibt Belohnungen für die Entdeckung neuer Sicherheitsanfälligkeiten und hat bereits 415 Berichte über potenzielle Probleme erhalten, von denen nur 64 als Sicherheitsanfälligkeiten bestätigt und 77 als nicht sicherheitsrelevante Fehler eingestuft wurden. So enthielten 66 % aller Berichte keine nützlichen Informationen und entzogen den Entwicklern Zeit, die besser für sinnvolle Aufgaben genutzt werden könnte.
Entwickler sind gezwungen, viel Zeit mit der Durchsicht nutzloser Berichte zu verschwenden und die darin enthaltenen Informationen mehrmals zu überprüfen, da die äußere Qualität der Präsentation zusätzliches Vertrauen in die Informationen weckt und der Eindruck entsteht, dass der Entwickler etwas missverstanden hat. Andererseits erfordert die Erstellung eines solchen Berichts minimale Anstrengungen von dem Bericht erstattenden Antragsteller, der sich nicht die Mühe macht, die Existenz eines realen Problems zu überprüfen, sondern einfach blind die von KI-Assistenten gelieferten Daten kopiert, in der Hoffnung, Glück im Wettlauf um die Belohnung zu haben.
Es werden zwei Beispiele für solche fehlerhaften Berichte angeführt. Einen Tag vor der geplanten Offenlegung von Informationen über die gefährliche Sicherheitsanfälligkeit im Oktober (CVE-2023-38545) wurde über Hackerone ein Bericht eingereicht, dass der Patch mit dem Fix öffentlich zugänglich gemacht wurde. In Wirklichkeit enthielt der Bericht eine von dem KI-Assistenten Google Bard zusammengestellte Mischung aus Fakten zu ähnlichen Problemen und Auszügen detaillierter Informationen zu früheren Sicherheitsanfälligkeiten. In der Folge wirkte die Information neu und aktuell, hatte jedoch keinen Bezug zur Realität.
Das zweite Beispiel bezieht sich auf die am 28. Dezember erhaltene Nachricht über einen Bufferüberlauf im WebSocket-Handler, die von einem Benutzer gesendet wurde, der bereits verschiedene Projekte über Hackerone über Sicherheitsanfälligkeiten informiert hatte. Als Methode zur Reproduktion des Problems wurden im Bericht allgemeine Hinweise zur Übermittlung einer modifizierten Anfrage angegeben, deren Wert größer war als die bei der Verwendung von strcpy verwendete Puffergröße. Der Bericht enthielt auch ein Beispiel für einen Fix (ein Beispiel für den Austausch von strcpy durch strncpy) und wies auf die Codezeile „strcpy(keyval, randstr)“ hin, in der der Antragsteller einen Fehler vermutete.
Der Entwickler überprüfte alles drei Mal und fand keine Probleme. Da der Bericht jedoch selbstbewusst verfasst war und sogar eine Lösung enthielt, hatte er das Gefühl, dass irgendwo etwas übersehen wurde. Der Versuch zu klären, wie es dem Forscher gelungen war, die vor dem Aufruf von strcpy vorhandene explizite Größenprüfung zu umgehen und wie die Puffergröße von keyval kleiner war als die Größe der gelesenen Daten, führte zu detaillierten, aber nicht weiterführenden Erklärungen, die nur offensichtlich allgemeine Gründe für Bufferüberläufe erörterten, die nicht mit dem spezifischen Curl-Code zusammenhingen. Die Antworten erinnerten an die Kommunikation mit einem KI-Assistenten, und nachdem er den halben Tag mit sinnlosen Versuchen verbracht hatte, herauszufinden, wie genau das Problem auftrat, war der Entwickler endgültig überzeugt, dass es tatsächlich keine Sicherheitsanfälligkeit gab.
Quelle: opennet.ru
