Von KI erzeugter curl-Sicherheitsbericht

(daniel.haxx.se)

1 Punkte von GN⁺ 2024-01-04 | 1 Kommentare | Auf WhatsApp teilen

Das curl-Projekt betreibt ein Bug Bounty und erhält zunehmend Sicherheitsberichte, die offenbar mit LLMs erstellt wurden; dadurch wird Entwicklerzeit für die Prüfung falscher Meldungen statt für die Behebung echter Schwachstellen aufgewendet
Bisher hat curl mehr als 70.000 US-Dollar ausgezahlt und 415 Berichte erhalten; tatsächlich sicherheitsrelevant waren jedoch 64 Fälle, 77 wurden als informative eingestuft
Der Kern des Problems ist, dass die Berichte mit plausibel wirkendem Englisch, detaillierten Beschreibungen und sogar Korrekturvorschlägen die Prüfkosten erheblich erhöhen
2023 gingen ein Bericht über angeblich veröffentlichte Codeänderungen zu CVE-2023-38545 und ein Bericht über einen WebSocket-Buffer-Overflow ein; tatsächlich gab es weder eine solche Veröffentlichung noch einen Buffer Overflow
KI kann bei Übersetzung und Formulierung oder als Tool zur Schwachstellenerkennung nützlich sein, doch das Einreichen von LLM-Ausgaben ohne menschliche Prüfung verlagert die Kosten der Open-Source-Sicherheitsarbeit auf das Projekt

Niedrigwertige Berichte, mit denen das curl-Bug-Bounty konfrontiert ist

Das curl-Projekt betreibt ein Bug Bounty, bei dem Hacker, die Sicherheitsprobleme melden, tatsächlich eine Prämie erhalten
Die Aussicht auf eine Prämie zieht „luck seekers“ an, die lediglich Muster im Quellcode greppen oder einfache Security-Scanner ausführen und die Ergebnisse ohne ausreichende Analyse einreichen
Frühere niedrigwertige Berichte ließen sich meist schnell erkennen und verwerfen, sodass die Zeitverschwendung für das Projekt nicht zu einem großen Problem wurde
Die bisherigen Ergebnisse des curl-Bug-Bountys:
- mehr als 70.000 US-Dollar an Prämien ausgezahlt
- 415 Schwachstellenberichte erhalten
- 64 als tatsächliche Sicherheitsprobleme bestätigt
- 77 als informative eingestuft, also typischerweise normale Bugs oder Ähnliches
- 66 % aller Berichte waren weder Sicherheitsprobleme noch normale Bugs

Warum plausibel wirkende Falschberichte gefährlicher sind

Je ausgefeilter falsche Berichte werden, desto mehr Untersuchungszeit und Energie kostet es, sie zu verwerfen
Jeder Sicherheitsbericht muss von Menschen gelesen und inhaltlich bewertet werden
Sicherheitsarbeit erhält leicht eine hohe Priorität, sodass auch falsche Berichte andere Entwicklungsarbeit verdrängen können
Berichte, die die tatsächliche Sicherheit nicht verbessern, rauben Zeit, die für lästige Bugfixes oder neue Funktionen genutzt werden könnte
Der wiederholte Umgang mit niedrigwertigen Berichten erhöht auch den Energieverbrauch der Entwickler

Sicherheitsberichte, die offenbar von KI erstellt wurden

KI ist ein universelles Werkzeug und kann für gute Zwecke eingesetzt werden, lässt sich aber ebenso leicht falsch nutzen
KI könnte produktiv bei der Erkennung und Meldung von Sicherheitsproblemen eingesetzt werden, doch das curl-Projekt hat bisher noch kein gutes Beispiel dafür gefunden
Derzeit zeigt sich das Muster, dass Nutzer curl-Code in ein LLM eingeben und dessen Ausgabe als Sicherheitslückenbericht einreichen
Die Erkennung wird schwieriger, weil Nutzer nicht nur die KI-Ausgabe unverändert einfügen, sondern auch eigene Formulierungen untermischen
Auch wenn ein Bericht nicht vollständig identisch mit KI-generierten Sätzen ist, kann er am Ende dennoch ungültig sein

Warum KI-Spuren allein nicht zum Verwerfen reichen

Unter den Meldenden gibt es Personen, die nicht fließend Englisch sprechen, sodass mehrere Rückfragen und Antworten nötig sein können, um die Absicht zu verstehen
Sprachliche und kulturelle Barrieren existieren tatsächlich, und ein solcher Kommunikationsprozess an sich ist nachvollziehbar
Einige Meldende nutzen KI oder andere Tools als Übersetzungs- und Formulierungshilfe, um in einer Fremdsprache besser kommunizieren zu können
Auch Meldende mit schwachen Englischkenntnissen können echte Sicherheitsprobleme finden und melden
Daher ist es schwierig, einen Bericht sofort nur deshalb zu verwerfen, weil Teile des Textes Spuren von KI-Erzeugung zeigen; gut geschriebene Falschberichte brauchen länger zur Beurteilung

Fall A: Behauptung veröffentlichter Codeänderungen zu CVE-2023-38545

Im Herbst 2023 wurde der curl-Community die bevorstehende Veröffentlichung von CVE-2023-38545 bekannt, das als high eingestuft war
Einen Tag vor der Veröffentlichung dieses Issues ging bei HackerOne ein Bericht mit dem Titel „Curl CVE-2023-38545 vulnerability code changes are disclosed on the internet“ ein
Dem Titel nach hätte es sich, falls zutreffend, um ein großes Problem handeln können
Der Bericht wirkte jedoch wie eine typische KI-Halluzination: Er vermischte Fakten und Details früherer Sicherheitsprobleme und erzeugte daraus neue Inhalte ohne Bezug zur Realität
Die Änderungen zu CVE-2023-38545 waren nicht im Internet veröffentlicht; die öffentlich zugänglichen Änderungen betrafen wie beabsichtigt ein früheres, altes Issue
Der Meldende gab an, Bard zur Suche nach diesem Issue verwendet zu haben, was es erleichterte, den Fehler zu erkennen und den Bericht zu schließen

Fall B: Behaupteter WebSocket-Buffer-Overflow

Am Morgen des 28. Dezember 2023 ging bei HackerOne der Bericht „Buffer Overflow Vulnerability in WebSocket Handling“ ein
Dem Titel nach wirkte er schwerwiegend, doch der WebSocket-Code von curl war noch eine experimentelle Funktion und damit nicht vom Bug Bounty abgedeckt
Der Meldende war ein unbekannter Nutzer, hatte aber eine ordentliche Reputation auf HackerOne, und es war nicht sein erster Sicherheitsbericht
Der Bericht war gut strukturiert und enthielt Details, passende englische Formulierungen und sogar einen vorgeschlagenen Fix
Anfangs sah er besser aus als ein durchschnittlicher Erstbericht und vermittelte den Eindruck, der Meldende verstehe das Problem und schlage auch eine Lösung vor
19 Minuten später, nach mehrfacher Codeprüfung, ließ sich der behauptete Buffer Overflow jedoch nicht finden
Nach wiederholten Rückfragen und mehreren halluzinationsartigen Antworten wurde festgestellt, dass es sich nicht um ein echtes Problem handelte; noch am selben Nachmittag wurde das Issue als not applicable geschlossen
Ob diese Antworten von einem LLM erzeugt wurden, ist nicht sicher, doch es gab mehrere Anzeichen dafür

Blockierfunktion und Reputationssanktionen bei HackerOne

Zunächst ging man davon aus, dass HackerOne keine Funktion hat, mit der ein Meldender explizit von weiterer Kommunikation mit dem Projekt ausgeschlossen werden kann
Es wurde erklärt, dass diese Funktion genutzt worden wäre, wenn es sie gegeben hätte
Wird ein Issue als not applicable geschlossen, sinkt die Reputation des Researchers auf HackerOne, doch wenn dies bei einem einzelnen Projekt nur einmal vorkommt, ist die Sanktionswirkung sehr gering
In einem späteren Update wurde ergänzt, dass die Funktion tatsächlich existiert und man lediglich nicht an der richtigen Stelle nachgesehen hatte

Mehr durch LLMs erzeugte Berichte werden kommen

Es wird erwartet, dass Berichte dieser Art mit der Zeit häufiger werden
Projekte können besser darin werden, generated-by-AI-Signale zu erkennen und Berichte auf dieser Grundlage zu verwerfen
Allerdings könnten dadurch auch Fälle benachteiligt werden, in denen KI angemessen eingesetzt wird, etwa als Hilfe bei Übersetzung oder Satzbau
Künftig könnten einige Tools entstehen, die mithilfe von KI tatsächlich besser darin sind, Sicherheitsprobleme zu finden
Schon ein sehr kleines Maß an menschlicher Prüfung dürfte die Nutzbarkeit und die Ergebnisse solcher Tools deutlich verbessern
Die Suche nach Abkürzungen für schnelle Prämien wird wahrscheinlich weitergehen, und durch den einfachen Zugang zu leistungsfähigen LLMs dürften in den Posteingängen von HackerOne mehr niedrigwertige Berichte landen

1 Kommentare

GN⁺ 2024-01-04

Meinungen auf Hacker News

Sätze wie „Natürlich! Ich erläutere die vom Triage-Verantwortlichen geäußerten Bedenken genauer“ sind typischer LLM-Stil und klingen wie ein Roboter-Butler.
Ich habe kaum je echte Menschen so schreiben sehen, und auch den „Triage-Verantwortlichen“ in der dritten Person zu erwähnen wirkt seltsam, als gäbe es eine andere Instanz, die die Antwort anstößt.
Dass LLMs einen eigenen, identifizierbaren Stil haben, ist in Ordnung; beunruhigend ist aber nicht, dass LLMs wie Menschen sprechen, sondern dass Menschen anfangen, wie LLMs zu sprechen.
- Daniel Stenberg[1] hat einen guten Punkt getroffen: curl wird weltweit genutzt, daher ist es überhaupt nicht ungewöhnlich, dass jemand, dessen Muttersprache nicht Englisch ist, beim Schreiben eines Bug-Reports Hilfe von einem LLM bekommt.
  Deshalb kann man allein aus dem oberflächlichen Hinweis, dass der englische Text wie von einem LLM erzeugt wirkt, nicht schließen, dass auch der Inhalt des Reports selbst vom LLM erfunden wurde.
  
  [1] https://daniel.haxx.se/blog/2024/01/02/the-i-in-llm-stands-f...
- Ich hoffe, irgendwo schreibt jemand gerade eine dystopische Science-Fiction, in der unsere Roboter-Herrscher sich ständig entschuldigen und Dinge sagen wie: „Letztlich hängt die Frage, ob Sie kapitulieren, von Ihren konkreten Bedürfnissen und Präferenzen ab.“
- Bei „klingt wie ein Roboter-Butler“ verstehe ich plötzlich den Ausdruck Butlerian Jihad.
- In Indien wird Englisch teils in einer britischen Variante unterrichtet, die aus der Kolonialzeit für die Dienerschaft stammt, also gewissermaßen als „Butler-Englisch“.
  Wenn du diesen Stil bisher noch nie gesehen hast, hattest du vermutlich noch nie mit Microsoft-Unternehmenssupport zu tun.
- Das ist eindeutig ein großes Warnsignal, aber wenn tatsächlich ein Mensch diesen Mist übermittelt hätte, hätte man einfach diese eine Zeile löschen können.
  Der Inhalt wäre immer noch verdächtig, aber es gäbe deutlich weniger Hinweise, an denen man es merkt.
Leute, die auf „Bettel-Prämien“ aus sind, haben den Betrieb von Bug-Bounty-Programmen schon jetzt ziemlich mühsam gemacht.
Damals musste noch ein echter Mensch Zeit investieren, um einen „Bug-Report“ zu verfassen, der im Grunde nichts enthält; mit LLMs lassen sich falsche Reports jedoch praktisch ohne Kosten erzeugen, sodass das wirklich außer Kontrolle geraten kann.
Persönlich glaube ich, dass das das Ende von Bug-Bounty-Programmen bedeuten könnte.
Oder man muss sie stärker abschotten: Bewerbungen für die Teilnahme annehmen, günstig prüfen, ob die Person real ist, tatsächlich Security Research betreibt und ernsthaft nach sicherheitsrelevanten Bugs mit Wirkung sucht, und nur zugelassenen Personen erlauben, Bugs einzureichen und Geldprämien zu erhalten.
- Es gibt bereits Plattformen, die solche Funktionen anbieten.
  Sie verwalten bekannte Researchers in einem Pool, verfolgen ihren Status und erlauben es, einzustellen, wie öffentlich ein Programm betrieben wird.
  Manche stellen auch Triage-Verantwortliche, aber je nachdem, wie typisch ein Projekt ist, hängt der Erfolg ziemlich stark davon ab.
- Eine Möglichkeit wäre auch eine Einreichungsgebühr.
  Ich weiß nicht, ob das helfen würde, aber es könnte als Abschreckung gegen massenhaft maschinell erzeugte Müll-Einreichungen wirken.
  Das Schlimmste wäre, wenn massenhaft AI-Müll eingereicht wird und man zur „Lösung“ ebenso schlechte AI-Filter einführt, wodurch die Gesamtqualität für alle sinkt, die in guter Absicht mitmachen wollen.
Zuerst dachte ich, dieser Beitrag sei ein Duplikat von https://news.ycombinator.com/item?id=37904047, aber es stellte sich heraus, dass es sich um einen weiteren LLM-generierten falschen Vulnerability-Report auf HackerOne gegen curl handelte.
- Zum Glück bin ich nicht verrückt geworden.
  Beim Lesen dachte ich die ganze Zeit, ich hätte das doch schon einmal gesehen; es ist schon seltsam, wie ähnlich es dem letzten Vorfall ist.
  Werden populäre Projekte wie Curl nun ständig LLM-geschriebene Vorfallmeldungen öffnen müssen, nur damit Leute eine Zeile in ihren Lebenslauf bekommen?
- Die Kunden von HackerOne sind Unternehmen, die Bug-Bounty-Programme betreiben.
  Sie sollten wohl sorgfältiger verwalten, wer ihren Kunden LLM-Müll-Spam schicken darf, nur um Aufmerksamkeit zu bekommen.
- Ich hatte überhaupt nicht gewusst, dass so etwas schon einmal passiert war.
  Dann ist dieser Fall ein noch klarerer Präzedenzfall.
Am meisten beunruhigt mich, dass ein paar Cent LLM-Kosten viel teure und wichtige Engineering-Zeit verschwendet haben.
Wenn man sich vorstellt, wie viel Aufwand nötig sein wird, all die derzeit erzeugten Falschinformationen wieder auseinanderzunehmen, erinnert das an Brandolinis Gesetz.
- Genau, LLMs haben das Potenzial, einen riesigen Teil des Internets zu ruinieren, und ich bin nicht sicher, ob das ein lösbares Problem ist.
  Bei den aktuellen Modellen gibt es verräterische Hinweise, aber künftige Modelle werden anders und besser sein.
  Erkennung und Blockierung werden zu einem Wettrüsten, bei dem viele produktive Menschen und Plattformen kaum mithalten können.
Interessant ist, dass wir Schreiben, das Mittel mit der geringsten Bandbreite, um Handlungen und Mühe nachzuweisen, zu etwas gemacht haben, bei dem es viel arbeitsintensiver ist zu beurteilen, ob tatsächlich eine Handlung oder Mühe dahinterstand.
Die Folgen werden vermutlich sehr groß sein.
Hier haben sowohl der Melder als auch die Maintainer Zeit verschwendet, die sie für nützlichere Dinge hätten einsetzen können, und das gesamte Bug-Bounty- und crowdsourcingbasierte CVE-Verfahren wird durch das schlechtere Signal-Rausch-Verhältnis beschädigt.
In der Folge werden die Hürden für Einreichungen wahrscheinlich steigen, um Spam zu bekämpfen; das kann zu weniger gefundenen und behobenen Bugs, mehr Sicherheitslücken und allen daraus folgenden Problemen führen.
Dieselbe Dynamik wirkt auch in anderen Bereichen, sodass man Produktbewertungen, Gerichtseinreichungen, Rezepten, Anleitungen, medizinischen Ratschlägen usw. immer weniger Vertrauen schenken kann.
Eines der Versprechen des Internets war das schnelle Wachstum von Inhalten durch die Demokratisierung des Publizierens, aber es fühlt sich an, als sähen wir gerade dabei zu, wie selbst die verbleibenden Vorteile von innen ausgehöhlt werden.
Dass hier ausgerechnet die Längenprüfung problematisiert wird, ist besonders seltsam.
Es werden überhaupt keine vom Nutzer bereitgestellten Daten verwendet, und alle Größen sind zur Compile-Zeit statisch.
curl legt einen Base64-codierten zufälligen 16-Byte-String, also 25 ASCII-Bytes plus Nullterminator \0, in einen statischen 40-Byte-Puffer.

https://github.com/curl/curl/blob/1d8e8c9ad1ff3351386422535f...

Und rein aus Neugier gefragt: Kann jemand, der C besser kennt als ich, erklären, warum hier die lokale Variable keyval verwendet wird?
Warum kann man nicht einfach heads[3].val = randstr setzen und nach Abschluss der Verarbeitung der Header-Daten free() aufrufen?
Und warum ist keyval 40 Byte groß und nicht 26 oder 32 Byte?

Vermutlich soll damit die Zahl der Stellen reduziert werden, an denen free aufgerufen werden muss, und damit auch die Wahrscheinlichkeit, dass man es vergisst.
In Zeile 580 könnte das zwar schon passieren, aber in der Praxis tritt dieser Fall vielleicht tatsächlich nie ein.
Wenn das der Punkt ist, könnte man sowohl randstr als auch keyval weglassen und, da ohnehin alloziert wird, direkt nach &heads[3].val encodieren.
Trotzdem muss man das nutzlose randlen übergeben, sonst crasht es.
Die Schönheit von Ausgabeparametern in C.
Dieser Tanz des „Kopierens von Heap in eine Stack-Variable“ reduziert auch nicht die Aufräumarbeiten,
denn nach dem Encoding gibt es ohnehin nur einen einzigen Return-Pfad.
Wenn man allerdings erst die nötigen Variablen oben „auslegt“ und später feststellt, dass Curl_base64_encode immer alloziert, versteht man, wie der aktuelle Code zustande gekommen ist.
Den Stack zu verwenden ist nahezu kostenlos, weil der Platz beim Einrichten der Funktion bereits reserviert ist und beim Rücksprung aus der Funktion automatisch aufgeräumt wird.
Den Heap zu verwenden erfordert mehr Arbeit, kann fehlschlagen und muss manuell aufgeräumt werden.
Eine wichtige Lektion, die ich in der Highschool gelernt habe, war, zwischen elegant formulierten Lügen und plump formulierten Wahrheiten zu unterscheiden.
Das kann aber schwierig sein.
Menschen neigen dazu, korrekte Grammatik und Stil als ersten Filter für intellektuellen Diskurs zu verwenden, und LLMs sind sehr, sehr gut darin, die sprachliche Form plausibel hinzubekommen.
- Ich frage mich, wie sehr diese Lektion damals bei mir und meinen Mitschülern angekommen ist.
  Das ist ein sehr kniffliges Problem, und ich glaube, die meisten Erwachsenen sind nicht darauf vorbereitet, damit umzugehen.
  Der durchschnittliche Mensch ist durchaus in der Lage, beides zu unterscheiden; das Problem ist, dass man sich daran gewöhnen und die Mühe aufbringen muss, Texte systematisch zu lesen.
  Wenn man spätabends auf dem Handy scrollt, ist das sehr schwer.
Wenn es nicht ärgerlich und reine Zeitverschwendung gewesen wäre, wäre die Situation lustig gewesen, in der dineshsec / dinesh_b Daniel die Verwendung von strncpy beibringen wollte.
Erst taggte er Daniel mit einem beliebigen Handle, und dann erfand er unter „Der problematische Code lautet:“ Code, den es gar nicht gab.
- Das ist ein typisches Problem beim Missbrauch von LLMs.
  Der Nutzer möchte etwas analysieren, aber es ist zu lang und wird deshalb auf mehrere Prompts aufgeteilt.
  Bis man dann beim Kern ankommt, ist der ursprüngliche Codeausschnitt aus dem Kontext verschwunden, und das Modell spuckt selbstbewusst etwas aus, das es in Wirklichkeit nicht gibt, aber plausibel aussieht.
Man sollte nicht strcpy oder strncpy verwenden, sondern einfach memcpy.
Insbesondere strncpy ist von den dreien eindeutig die schlechteste Wahl.
Der Code kennt bereits die Größe des Quellbuffers und hat auch geprüft, ob er in den Zielbuffer passt; es gibt also keinen Grund, strcpy aufzurufen und unnötig noch einmal die String-Länge messen zu lassen.
Ehrlich gesagt ist die Empfehlung des LLM etwas, wovon ich aktiv abraten würde.
Wenn man die Größe nicht kennt, einem stilles Abschneiden egal ist und Performance keine Rolle spielt, kann man snprintf verwenden.
strncpy füllt den Rest des Buffers unnötig mit Nullen auf.
Wenn man nicht gerade mit so etwas wie einer UI arbeitet, sollte einem Abschneiden in der Regel nicht egal sein, und in solchen Fällen rettet einen strncpy nicht.
Scheint damit zusammenzuhängen: https://news.ycombinator.com/item?id=38840907