Daniel Stenberg, der Autor des Tools curl zur Übertragung von Daten über das Netzwerk, hat die Verwendung von KI-Tools zur Erstellung von Sicherheitsberichte kritisiert. Solche Berichte enthalten detaillierte Informationen, sind in normalem Sprachstil verfasst und wirken qualitativ hochwertig, können jedoch ohne sorgfältige Analyse irreführend sein, indem sie echte Probleme durch qualitativ minderwertige Inhalte ersetzen.
Das Curl-Projekt bezahlt 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. Damit enthielten 66 % aller Berichte keine nützlichen Informationen und nahmen den Entwicklern wertvolle Zeit, die sie besser für produktivere Aufgaben hätten nutzen können.
Entwickler verbringen unnötig viel Zeit mit der Analyse nutzloser Berichte und überprüfen die dort angegebenen Informationen mehrfach, da die äußere Qualität der Präsentation zusätzliches Vertrauen in die Informationen schafft und der Eindruck entsteht, dass der Entwickler etwas missverstanden hat. Andererseits erfordert die Erstellung eines solchen Berichts minimale Anstrengungen seitens des Antragstellers, der sich nicht die Mühe macht, das Vorhandensein eines tatsächlichen Problems zu überprüfen, sondern einfach blind Daten kopiert, die von KI-Helfern bereitgestellt wurden, in der Hoffnung, Glück im Kampf um die Belohnung zu haben.
Es werden zwei Beispiele solcher Müllberichte angeführt. Einen Tag vor der geplanten Bekanntgabe der Informationen über die gefährliche Schwachstelle im Oktober (CVE-2023-38545) wurde über Hackerone ein Bericht eingereicht, dass der Patch mit der Behebung öffentlich zugänglich geworden sei. In Wirklichkeit enthielt der Bericht eine von dem KI-Helfer Google Bard zusammengestellte Mischung aus Fakten über ähnliche Probleme und Auszügen aus detaillierten Informationen über vergangene Schwachstellen. Letztendlich erschien die Information neu und aktuell, hatte jedoch keinen Bezug zur Realität.
Das zweite Beispiel bezieht sich auf die am 28. Dezember erhaltene Meldung über einen Buffer Overflow im WebSocket-Handler, die von einem Benutzer gesendet wurde, der bereits verschiedene Projekte über Hackerone über Sicherheitslücken informiert hatte. Als Methode zur Reproduktion des Problems wurden im Bericht allgemeine Hinweise auf das Senden einer veränderten Anfrage genannt, deren Werte das beim Kopieren mit strcpy verwendete Buffer übersteigen. Der Bericht enthielt auch ein Beispiel für eine Korrektur (Beispiel für den Austausch von strcpy gegen strncpy) und verwies auf die Codezeile „strcpy(keyval, randstr)“, in der laut des Meldenden ein Fehler vorlag.
Der Entwickler hat alles dreimal überprüft und keine Probleme gefunden, aber da der Bericht selbstbewusst verfasst war und sogar eine Korrektur enthielt, entstand der Eindruck, dass irgendwo etwas übersehen wurde. Der Versuch, zu klären, wie es dem Forscher gelungen ist, die offensichtliche Größenüberprüfung vor dem Aufruf von strcpy zu umgehen und wie die Größe des Puffers keyval kleiner war als die Menge der gelesenen Daten, führte zu detaillierten, aber nicht informativen Erklärungen, die lediglich die allgemeinen Ursachen für Bufferüberläufe wiederholten, ohne Bezug auf den spezifischen Curl-Code zu nehmen. Die Antworten erinnerten an Gespräche mit einem KI-Assistenten, und nachdem er einen halben Tag mit sinnlosen Versuchen verbracht hatte, herauszufinden, wie das Problem genau auftritt, war der Entwickler schließlich überzeugt, dass es tatsächlich keine Schwachstelle gab.
Quelle: opennet.ru
