Daniel Stenberg, autor narzędzia do przesyłania i odbierania danych przez sieć curl, skrytykował wykorzystanie narzędzi AI do tworzenia raportów o lukach w zabezpieczeniach. Takie raporty zawierają szczegółowe informacje, są napisane w normalnym języku i wyglądają na wysokiej jakości, ale bez przemyślanej analizy mogą wprowadzać w błąd, zastępując rzeczywiste problemy jakościowo wyglądającym śmieciowym materiałem.
Projekt Curl wypłaca nagrody za odkrywanie nowych luk i już otrzymał 415 raportów o potencjalnych problemach, z których jedynie 64 zostały potwierdzone jako luki, a 77 jako błędy niezwiązane z bezpieczeństwem. W ten sposób 66% wszystkich raportów nie zawierało żadnych użytecznych informacji i tylko zabierało czas programistom, który mogliby wykorzystać na coś pożytecznego.
Programiści zmuszeni są marnować dużo czasu na analizowanie bezużytecznych raportów i wielokrotne weryfikowanie podanych tam informacji, ponieważ zewnętrzna jakość ich wykonania buduje dodatkowe zaufanie do informacji i rodzi wrażenie, że programista, coś źle zrozumiał. Z drugiej strony, stworzenie takiego raportu wymaga minimalnego wysiłku ze strony zgłaszającego, który nie zawraca sobie głowy weryfikacją istnienia rzeczywistego problemu, a jedynie ślepo kopiuje dane otrzymane od asystentów AI, licząc na szczęście w walce o nagrodę.
Podano dwa przykłady takich bezsensownych raportów. Dzień przed planowanym ujawnieniem informacji o październikowej niebezpiecznej luce (CVE-2023-38545) przez Hackerone wysłano raport mówiący, że poprawka z rozwiązaniem została udostępniona publicznie. W rzeczywistości raport zawierał skomponowaną przez asystenta AI Google Barda mieszankę faktów o podobnych problemach i fragmentów szczegółowych informacji o wcześniejszych lukach. W rezultacie informacje wyglądały na nowe i aktualne, ale nie miały związku z rzeczywistością.
Drugi przykład dotyczy zgłoszenia o przepełnieniu bufora w obsłudze WebSocket, przesłanego przez użytkownika 28 grudnia, który wcześniej informował różne projekty o podatnościach za pośrednictwem Hackerone. Jako metoda reprodukcji problemu w raporcie wskazano ogólne sformułowania dotyczące przesyłania zmodyfikowanego żądania, którego rozmiar przekraczał rozmiar bufora używanego podczas kopii za pomocą strcpy. W raporcie podano również przykład poprawki (przykład zastąpienia strcpy przez strncpy) oraz link do linii kodu „strcpy(keyval, randstr)”, w której, zdaniem zgłaszającego, wystąpił błąd.
Programista trzykrotnie wszystko sprawdził i nie znalazł żadnych problemów, jednak ponieważ raport był napisany pewnie i zawierał nawet poprawkę, pojawiło się wrażenie, że coś umyka. Próba wyjaśnienia, jak badaczowi udało się obejść dostępną przed wywołaniem strcpy wyraźną kontrolę rozmiaru oraz jak rozmiar bufora keyval okazał się mniejszy od rozmiaru odczytanych danych, doprowadziła do uzyskania szczegółowych, ale nic nie wnoszących wyjaśnień, które tylko rozwodziły się nad oczywistymi, ogólnymi przyczynami występowania przepełnienia bufora, niezwiązanego z konkretnym kodem Curl. Odpowiedzi przypominały rozmowę z asystentem AI i po spędzeniu pół dnia na bezsensownych próbach dowiedzenia się, jak dokładnie objawia się problem, programista całkowicie się przekonał, że tak naprawdę nie ma żadnej podatności.
Źródło: opennet.ru
