Daniels Stenbergs, utilīta datu saņemšanai un nosūtīšanai, izmantojot tīkla loku, autors, kritizēja AI rīku izmantošanu, veidojot ievainojamības ziņojumus. Šādi pārskati ietver detalizētu informāciju, ir rakstīti parastā valodā un izskatās kvalitatīvi, taču bez pārdomātas analīzes patiesībā tie var būt tikai maldinoši, reālas problēmas aizvietojot ar kvalitatīvu atkritumu saturu.
Curl projekts maksā atlīdzību par jaunu ievainojamību identificēšanu un jau ir saņēmis 415 ziņojumus par iespējamām problēmām, no kuriem tikai 64 tika apstiprināti kā ievainojamības un 77 kā ar drošību nesaistītas kļūdas. Tādējādi 66% no visiem ziņojumiem nesaturēja nekādu noderīgu informāciju un tikai atņēma izstrādātājiem laiku, ko varēja tērēt kam noderīgam.
Izstrādātāji ir spiesti tērēt daudz laika, analizējot bezjēdzīgus pārskatus un vairākkārt pārbaudot tajos esošo informāciju, jo dizaina ārējā kvalitāte rada papildu pārliecību par informāciju un rodas sajūta, ka izstrādātājs kaut ko ir pārpratis. No otras puses, šāda ziņojuma ģenerēšana prasa minimālu piepūli no pieteikuma iesniedzēja, kurš neuztraucas pārbaudīt patiesu problēmu, bet vienkārši akli kopē no AI palīgiem saņemtos datus, cerot uz veiksmi cīņā par atlīdzību.
Ir sniegti divi šādu atkritumu ziņojumu piemēri. Dienu pirms plānotās informācijas atklāšanas par bīstamo oktobra ievainojamību (CVE-2023-38545), ar Hackerone starpniecību tika nosūtīts ziņojums, ka ielāps ar labojumu kļuvis publiski pieejams. Faktiski ziņojumā bija ietverti fakti par līdzīgām problēmām un detalizētas informācijas fragmenti par pagātnes ievainojamībām, ko apkopojis Google AI palīgs Bards. Rezultātā informācija izskatījās jauna un atbilstoša, un tai nebija nekādas saistības ar realitāti.
Otrs piemērs attiecas uz 28. decembrī saņemto ziņojumu par WebSocket apdarinātāja bufera pārpildīšanu, ko nosūtījis lietotājs, kurš ar Hackerone starpniecību jau bija informējis dažādus projektus par ievainojamībām. Kā problēmas reproducēšanas metode ziņojumā bija ietverti vispārīgi vārdi par modificēta pieprasījuma nodošanu, kuras vērtība ir lielāka par bufera lielumu, ko izmanto kopēšanai ar strcpy. Ziņojumā tika sniegts arī labojuma piemērs (piemērs strcpy aizstāšanai ar strncpy) un norādīta saite uz koda rindiņu “strcpy(keyval, randstr)”, kurā, pēc pieteikuma iesniedzēja domām, bija kļūda.
Izstrādātājs vēlreiz visu pārbaudīja trīs reizes un nekādas problēmas neatrada, taču, tā kā atskaite bija uzrakstīta pārliecinoši un pat saturēja labojumu, radās sajūta, ka kaut kur kaut kas pietrūkst. Mēģinājums noskaidrot, kā pētniekam izdevās apiet precīzo lieluma pārbaudi pirms strcpy izsaukuma un kā atslēgvārda bufera izmērs izrādījās mazāks par nolasīto datu lielumu, noveda pie detalizētiem, bet bez papildu informācijas paskaidrojumiem. kas tikai košļāja par acīmredzamajiem bufera pārpildes cēloņiem, kas nav saistīti ar konkrētu Curl kodu. Atbildes atgādināja saziņu ar AI palīgu, un pēc tam, kad pusi dienas bija veltījuši bezjēdzīgiem mēģinājumiem noskaidrot, kā tieši problēma izpaužas, izstrādātājs beidzot pārliecinājās, ka ievainojamības patiesībā nav.
Avots: opennet.ru