Daniel Stenberg, a curl hálózati adatküldő és -fogadó eszköz szerzője bírálta az AI-eszközök használatát a sebezhetőségi jelentések készítése során. Az ilyen jelentések részletes információkat tartalmaznak, normális nyelven íródnak és jó minőségűnek tűnnek, de alapos elemzés nélkül valójában félrevezethetik a felhasználókat, helyettesítve a valós problémákat egy jól megírt, de haszontalan tartalommal.
A Curl projekt jutalmat kínál új sebezhetőségek felfedezéséért, és eddig 415 potenciális problémajelentést kapott, amelyekből csak 64 bizonyult sebezhetőségnek, míg 77 nem biztonsági hibának. Így a bejelentett esetek 66%-a nem tartalmazott hasznos információkat, és csupán időt pazarolt a fejlesztők számára, amit hasznosabb tevékenységekre is fordíthattak volna.
A fejlesztők kénytelenek sok időt vesztegetni haszontalan jelentések elemezésére, és többször is ellenőrizni a jelentésekben megadott információkat, mivel a külső megjelenés plusz bizalmat kelt az információk iránt, és azt a benyomást keltik, hogy a fejlesztő valamit nem értett meg. Másrészről az ilyen jelentés elkészítése minimális erőfeszítést igényel a bejelentőtől, aki nem fárad a valós probléma meglétének ellenőrzésével, hanem egyszerűen csak a mesterséges intelligencia asszisztensek által kibővített adatokat másolja, bízva a szerencséjében a jutalom megszerzése érdekében.
Két példát említünk az ilyen haszontalan jelentésekre. Egy nappal a tervezett októberi veszélyes sebezhetőség (CVE-2023-38545) nyilvánosságra hozatala előtt a Hackerone-on egy jelentést küldtek be, amely arról tájékoztatott, hogy a javító csomag nyilvánosan hozzáférhetővé vált. A jelentés valójában a Google Bard AI-asszisztens által készült tények és korábbi sebezhetőségekről szóló részletes információk összegzését tartalmazta. Ennek eredményeként az információ új és aktuális volt, de nem volt összhangban a valósággal.
A második példa egy, december 28-án kapott üzenetre vonatkozik, amely a WebSocket kezelőben előforduló puffertúlcsordulásról szól, és amelyet a felhasználó már értesített különböző projektekről a Hackerone-on keresztül. A problémakör ismétlésének módszerében általános megfogalmazások szerepeltek, amelyek az átkonfigurált kérés átadására vonatkoztak, amelynek értékmérete meghaladta azt a méretet, amelyet a strcpy használatával való másolás során alkalmaztak. A jelentésben egy javítási példa is szerepelt (a strcpy strncpy-ra való cseréje), valamint egy hivatkozás a „strcpy(keyval, randstr)” kódvonallal, amelyben a bejelentő véleménye szerint hiba található.
A fejlesztő háromszor mindent ellenőrzött, és nem talált problémát, de mivel a jelentés magabiztosan volt megfogalmazva, és még javítást is tartalmazott, úgy tűnt, hogy valami elkerüli a figyelmet. Azt próbálták tisztázni, hogyan tudta a kutató megkerülni a strcpy hívása előtt meglévő méretellenőrzést, és hogyan lehetséges, hogy a keyval pufferméret kisebb volt a beolvasott adatoknál, de részletes magyarázatokat kaptak, amelyek nem nyújtottak további információt, amelyek csak az általános puffertúlcsordulás okait ecsetelték, amelyek nem kapcsolódtak a Curl konkrét kódjához. A válaszok emlékeztettek egy AI-asszisztenssel folytatott beszélgetésre, és miután fél napot töltött azzal, hogy értelmetlen próbálkozásokat kíséreljen meg kideríteni, hogy pontosan hogyan jelentkezik a probléma, a fejlesztő véglegesen megbizonyosodott arról, hogy valójában nincs sérülékenység.
Forrás: opennet.ru
