Daniel Stenberg, autor narzędzia do odbierania i wysyłania danych po sieci curl, skrytykował wykorzystanie narzędzi AI przy tworzeniu raportów o podatnościach. Takie raporty zawierają szczegółowe informacje, są napisane normalnym językiem i wyglądają na wysokiej jakości, ale bez przemyślanej analizy w rzeczywistości mogą jedynie wprowadzać w błąd, zastępując rzeczywiste problemy śmieciową treścią wyglądającą na jakość.
Projekt Curl płaci nagrody za identyfikację nowych luk i otrzymał już 415 raportów o potencjalnych problemach, z czego tylko 64 potwierdzono jako luki, a 77 jako błędy niezwiązane z bezpieczeństwem. Zatem 66% wszystkich raportów nie zawierało żadnych przydatnych informacji, a jedynie zabierało programistom czas, który można było przeznaczyć na coś pożytecznego.
Programiści są zmuszeni tracić dużo czasu na analizowanie bezużytecznych raportów i kilkakrotne sprawdzanie zawartych w nich informacji, ponieważ zewnętrzna jakość projektu stwarza dodatkowe zaufanie do informacji i pojawia się wrażenie, że programista coś źle zrozumiał. Z drugiej strony wygenerowanie takiego raportu wymaga minimalnego wysiłku ze strony zgłaszającego, który nie zawraca sobie głowy sprawdzaniem, czy faktycznie jest to problem, a po prostu na ślepo kopiuje dane otrzymane od asystentów AI, licząc na szczęście w walce o nagrodę.
Podano dwa przykłady takich raportów o śmieciach. Dzień przed planowanym ujawnieniem informacji o niebezpiecznej październikowej luce (CVE-2023-38545) za pośrednictwem Hackerone rozesłany został raport, że łatka z poprawką została udostępniona publicznie. W rzeczywistości raport zawierał mieszankę faktów na temat podobnych problemów oraz fragmenty szczegółowych informacji na temat luk w zabezpieczeniach z przeszłości, opracowanych przez asystenta Google ds. sztucznej inteligencji, Barda. W rezultacie informacje wydawały się nowe i istotne i nie miały żadnego związku z rzeczywistością.
Drugi przykład dotyczy otrzymanej 28 grudnia wiadomości o przepełnieniu bufora w obsłudze WebSocket, wysłanej przez użytkownika, który za pośrednictwem Hackerone informował już różne projekty o podatnościach. Jako metodę odtworzenia problemu raport zawierał ogólne słowa dotyczące przekazywania zmodyfikowanego żądania o wartości większej niż rozmiar bufora używanego podczas kopiowania za pomocą strcpy. W raporcie podano także przykład poprawki (przykład zastąpienia strcpy strncpy) oraz wskazano odnośnik do linijki kodu „strcpy(keyval, randstr)”, która zdaniem zgłaszającego zawierała błąd.
Deweloper dokładnie sprawdził wszystko trzy razy i nie znalazł żadnych problemów, ale ponieważ raport został napisany pewnie, a nawet zawierał korektę, wydawało się, że czegoś gdzieś brakuje. Próba wyjaśnienia, w jaki sposób badaczowi udało się ominąć jawną kontrolę rozmiaru występującą przed wywołaniem strcpy i w jaki sposób rozmiar bufora klucza okazał się mniejszy niż rozmiar odczytanych danych, doprowadziła do szczegółowych, ale nie niosących ze sobą dodatkowych informacji wyjaśnień który tylko żuł oczywiste, częste przyczyny przepełnienia bufora niezwiązane z konkretnym kodem Curl. Odpowiedzi przypominały komunikację z asystentem AI i po spędzeniu pół dnia na bezsensownych próbach dowiedzenia się, jak dokładnie objawia się problem, programista w końcu był przekonany, że tak naprawdę nie ma żadnej luki.
Źródło: opennet.ru