Daniel Stenberg, a hálózaton keresztüli adatok fogadására és küldésére szolgáló segédprogram szerzője bírálta az AI-eszközök használatát a sebezhetőségi jelentések készítésekor. Az ilyen jelentések részletes információkat tartalmaznak, normál nyelven íródnak és jó minőségűnek tűnnek, de átgondolt elemzés nélkül a valóságban csak félrevezetőek lehetnek, a valódi problémákat minőséginek tűnő szeméttartalommal helyettesíthetik.
A Curl projekt jutalmat fizet az új sebezhetőségek azonosításáért, és már 415 bejelentést kapott potenciális problémákról, amelyek közül csak 64-et erősítettek meg sebezhetőségként, 77-et pedig nem biztonsági hibaként. Így az összes jelentés 66%-a semmilyen hasznos információt nem tartalmazott, és csak annyi időt vett el a fejlesztőktől, amit valami hasznosra fordíthattak volna.
A fejlesztők kénytelenek sok időt vesztegetni a haszontalan jelentések elemzésével és az ott található információk többszöri ellenőrzésével, mivel a design külső minősége további bizalmat kelt az információban, és az az érzés, hogy a fejlesztő valamit félreértett. Másrészt egy ilyen jelentés elkészítése minimális erőfeszítést igényel a pályázótól, aki nem vesz részt a valódi probléma ellenőrzésével, hanem egyszerűen vakon másolja az AI-asszisztensektől kapott adatokat, remélve, hogy szerencséje lesz a jutalomért folytatott küzdelemben.
Két példát mutatunk be ilyen szemétjelentésekre. A veszélyes októberi sérülékenységgel (CVE-2023-38545) kapcsolatos információk tervezett nyilvánosságra hozatala előtti napon a Hackerone-n keresztül jelentést küldtek arról, hogy a javítást tartalmazó javítás nyilvánossá vált. Valójában a jelentés hasonló problémákra vonatkozó tények keverékét, valamint a Google mesterséges intelligencia asszisztense, Bard által összeállított, korábbi sebezhetőségekről szóló részleteket tartalmazott. Ennek eredményeként az információ újnak és relevánsnak tűnt, és nem volt kapcsolatban a valósággal.
A második példa a WebSocket kezelő puffertúlcsordulásáról szóló, december 28-án kapott üzenetre vonatkozik, amelyet egy olyan felhasználó küldött, aki a Hackerone-on keresztül már tájékoztatott különböző projekteket a sebezhetőségekről. A probléma reprodukálására szolgáló módszerként a jelentés általános szavakat tartalmazott egy módosított kérés átadásáról, amelynek értéke nagyobb, mint az strcpy-vel másoláskor használt puffer mérete. A jelentésben szerepelt egy javítási példa is (példa az strcpy strncpy-vel való cseréjére), valamint egy hivatkozást a „strcpy(keyval, randstr)” kódsorra, amely a kérelmező szerint hibát tartalmazott.
A fejlesztő háromszor mindent átellenőrzött, és nem talált hibát, de mivel a jelentés magabiztosan készült, sőt még javítást is tartalmazott, volt egy olyan érzés, hogy valami hiányzik valahonnan. Annak tisztázására tett kísérlet, hogy a kutatónak miként sikerült megkerülnie az strcpy hívás előtti explicit méretellenőrzést, és hogyan bizonyult a kulcspuffer mérete kisebbnek, mint az olvasott adatok mérete, részletes, de további információkat nem tartalmazó magyarázatokhoz vezetett. hogy csak a puffertúlcsordulás nyilvánvaló gyakori okain rágódott, amelyek nem kapcsolódnak konkrét Curl kódhoz. A válaszok egy mesterséges intelligencia asszisztenssel való kommunikációra emlékeztettek, és miután fél napot eltöltöttek értelmetlen kísérletekkel, hogy kiderítsék, pontosan miben nyilvánul meg a probléma, a fejlesztő végül meggyőződött arról, hogy valójában nincs sebezhetőség.
Forrás: opennet.ru