Daniel Stenberg-ek, datuak jasotzeko eta bidaltzeko sareko kiribilduaren bidez, kritikatu zuen AI tresnen erabilera ahultasun-txostenak sortzean. Txosten horiek informazio zehatza biltzen dute, hizkuntza arruntean idatzita daude eta kalitate handiko itxura dute, baina errealitatean azterketa sakonik egin gabe engainagarriak izan daitezke soilik, benetako arazoak kalitatezko zabor edukiekin ordezkatuz.
Curl proiektuak ahultasun berriak identifikatzeko sariak ordaintzen ditu eta dagoeneko arazo potentzialen 415 txosten jaso ditu, horietatik 64 bakarrik baieztatu ziren ahultasun gisa eta 77 segurtasunez kanpoko akats gisa. Horrela, txosten guztien % 66k ez zuten informazio baliagarririk jasotzen eta garatzaileei denbora bakarrik kendu zien erabilgarria zerbaitetan gastatu zitekeen.
Garatzaileak denbora asko galtzera behartuta daude alferrikako txostenak analizatzen eta bertan jasotako informazioa hainbat aldiz egiaztatzen, diseinuaren kanpoko kalitateak informazioarengan konfiantza gehigarria sortzen duelako eta garatzaileak zerbait gaizki ulertu duelako sentsazioa baitago. Bestalde, txosten hori sortzeak eskatzaileari gutxieneko ahalegina eskatzen dio, benetako arazoren bat egiaztatzeko trabarik egiten ez duena, baizik eta itsu-itsuan kopiatzen ditu AI laguntzaileengandik jasotako datuak, sari bat jasotzeko borrokan zortea izango duelakoan.
Horrelako zabor-txostenen bi adibide ematen dira. Urriaren ahultasun arriskutsuari buruzko informazioa (CVE-2023-38545) aurreikusitako informazioa ezagutarazi aurreko egunean, Hackerone-ren bidez txosten bat bidali zen, konponketa duen adabakia publikoki eskuragarri jarri zela. Izan ere, txostenak antzeko arazoei buruzko gertakari eta iraganeko ahultasunei buruzko informazio zehatzaren zatiak biltzen zituen Bard Google-ren AI laguntzaileak. Ondorioz, informazioa berria eta garrantzitsua zirudien, eta ez zuen errealitatearekin loturarik.
Bigarren adibidea abenduaren 28an WebSocket kudeatzailean buffer gainezkatzeari buruz jasotako mezu bati buruzkoa da, jada Hackerone bidez ahultasunei buruz hainbat proiekturen berri izan zuen erabiltzaile batek bidalia. Arazoa erreproduzitzeko metodo gisa, txostenak strcpy-rekin kopiatzerakoan erabilitako buffer-aren tamaina baino balio handiagoa duen eskaera aldatu bat pasatzeari buruzko hitz orokorrak biltzen zituen. Txostenak zuzenketa baten adibide bat ere eman zuen (strcpy strncpy-rekin ordezkatzeko adibide bat) eta "strcpy(keyval, randstr)" kode-lerrorako esteka bat adierazi zuen, eskatzailearen arabera, akats bat zuen.
Garatzaileak hiru aldiz egiaztatu zuen dena eta ez zuen arazorik aurkitu, baina txostena konfiantzaz idatzi zenez eta zuzenketa bat ere izan zuenez, nonbait zerbait falta zenaren sentsazioa zegoen. Ikertzaileak strcpy deiaren aurretik dagoen tamaina egiaztapen esplizitua saihestea nola lortu zuen argitzeko eta gako-buffer-aren tamaina irakurritako datuen tamaina baino txikiagoa izan zen argitzeko, informazio gehigarririk, baina informazio gehigarririk ekarri ez zuen argitzeko. Curl kode espezifikoarekin zerikusirik ez duten buffer gainezkatzearen kausa arruntak bakarrik murtxikatu zituen. Erantzunek AI laguntzaile batekin komunikatzea gogorarazten zuten, eta arazoa zehazki nola agertzen den jakiteko egun erdia alferrikako saiakeretan igaro ondoren, garatzailea azkenean konbentzitu zen ez zegoela ahultasunik.
Iturria: opennet.ru