Дэніэл Cтэнберг (Daniel Stenberg), аўтар утыліты для атрымання і адпраўкі дадзеных па сетцы curl, выступіў з крытыкай выкарыстання AI-інструментаў пры стварэнні справаздач аб уразлівасцях. Падобныя справаздачы ўключаюць дэталёвыя звесткі, напісаны нармальнай мовай і выглядаюць якаснымі, але без удумлівага аналізу на справе могуць толькі ўводзіць у зман, падмяняючы рэальныя праблемы якасна выглядаючым смеццевым змесцівам.
Праект Curl выплачвае ўзнагароды за выяўленне новых уразлівасцяў і ўжо атрымаў 415 справаздач аб патэнцыйных праблемах, з якіх толькі 64 былі пацверджаны як уразлівасці, а 77 як не злучаныя з бяспекай памылкі. Такім чынам 66% усіх справаздач не ўтрымлівалі якіх-небудзь карысных звестак і толькі адабралі ў распрацоўшчыкаў час, які можна было патраціць на нешта карыснае.
Распрацоўнікі змушаныя марна марнаваць шмат часу на разбор бескарысных справаздач і пераправяраць паказаныя там звесткі па некалькі разоў, бо вонкавая якасць афармлення выклікае дадатковы давер да інфармацыі і ўзнікае адчуванне, што распрацоўнік, штосьці не зразумеў. З іншага боку фармаванне падобнай справаздачы патрабуе мінімальных высілкаў ад заяўніка, які не турбуе сябе праверкай наяўнасці рэальнай праблемы, а проста слепа капіюе дадзеныя атрыманыя ад AI-памагатых, спадзеючыся на шанцаванне ў дужанні за атрыманне ўзнагароды.
Прыводзіцца два прыклады такіх смеццевых справаздач. За дзень да планавага расчынення звестак аб кастрычніцкай небяспечнай уразлівасці (CVE-2023-38545) праз Hackerone была адпраўленая справаздача аб тым, што патч з выпраўленнем патрапіў у адчынены доступ. На справе справаздача ўтрымоўваў скампанаваную AI-памагатым Google Bard сумесь з фактаў аб падобных праблемах і ўрыўкаў дэталёвых звестак аб мінулых уразлівасцях. У выніку інфармацыя выглядала новай і актуальнай, не ня мела вязі з рэальнасцю.
Другі прыклад закранае атрыманае 28 снежня паведамленне аб перапаўненні буфера ў апрацоўшчыку WebSocket, адпраўленае карыстачом, ужо які інфармаваў аб уразлівасцях розныя праекты праз Hackerone. У якасці метаду паўтарэння праблемы ў справаздачы паказваліся агульныя словы аб перадачы змененага запыту з памерам значэння, які перавышае памер буфера, які выкарыстоўваецца пры капіяванні пры дапамозе strcpy. У справаздачы таксама прыводзіўся прыклад выпраўлення (прыклад замены strcpy на strncpy) і ўказвалася спасылка на радок кода "strcpy(keyval, randstr)", у якім на думку заяўніка была памылка.
Распрацоўнік тры разы ўсё пераправерыў і не знайшоў якіх-небудзь праблем, але так як справаздача напісана ўпэўнена і нават утрымліваў выпраўленне, узнікла адчуванне, што недзе нешта прапускае. Спроба ўдакладніць як даследніку атрымалася абыйсці прысутную да выкліку strcpy відавочную праверку памеру і як памер буфера keyval апынуўся менш памеру прачытаных дадзеных, прывяла да атрымання падрабязных, але не апорных дадатковай інфармацыі, тлумачэнняў, якія толькі разжоўвалі відавочныя агульныя чыннікі ўзнікнення перапаўнення канкрэтным кодам Curl. Адказы нагадвалі зносіны з AI-памагатым і выдаткаваўшы падлогу дня на бессэнсоўныя спробы пазнаць як менавіта выяўляецца праблема, распрацоўнік канчаткова пераканаўся, што ніякай уразлівасці на справе няма.
Крыніца: opennet.ru