Daniel Stenberg, joka on kirjoittanut apuohjelman tietojen vastaanottamiseen ja lähettämiseen verkon yli, kritisoi tekoälytyökalujen käyttöä haavoittuvuusraporttien luomisessa. Sellaiset raportit sisältävät yksityiskohtaista tietoa, ne on kirjoitettu normaalilla kielellä ja näyttävät laadukkailta, mutta ilman harkittua analyysia ne voivat todellisuudessa olla vain harhaanjohtavia ja korvaavat todelliset ongelmat laadukkaalla roskasisällöllä.
Curl-projekti maksaa palkkioita uusien haavoittuvuuksien tunnistamisesta ja on saanut jo 415 ilmoitusta mahdollisista ongelmista, joista vain 64 vahvistettiin haavoittuvuuksiksi ja 77 ei-tietoturvavirheiksi. Siten 66 % kaikista raporteista ei sisältänyt mitään hyödyllistä tietoa ja veivät kehittäjiltä vain aikaa, jonka olisi voitu käyttää johonkin hyödylliseen.
Kehittäjät joutuvat tuhlaamaan paljon aikaa turhien raporttien jäsentämiseen ja niiden sisältämien tietojen tarkistamiseen useita kertoja, koska suunnittelun ulkoinen laatu luo lisää luottamusta tietoon ja syntyy tunne, että kehittäjä on ymmärtänyt jotain väärin. Toisaalta tällaisen raportin luominen vaatii minimaalista vaivaa hakijalta, joka ei vaivaudu tarkistamaan todellista ongelmaa, vaan kopioi yksinkertaisesti sokeasti tekoälyassistenteilta saadut tiedot toivoen onnea taistelussa palkinnon saamiseksi.
Tällaisista jäteraporteista annetaan kaksi esimerkkiä. Päivää ennen suunniteltua vaarallista lokakuun haavoittuvuutta (CVE-2023-38545) koskevien tietojen julkistamista Hackeronen kautta lähetettiin raportti, että korjaustiedoston sisältävä korjaustiedosto on tullut julkisesti saataville. Itse asiassa raportti sisälsi yhdistelmän faktoja samanlaisista ongelmista ja katkelmia yksityiskohtaisista tiedoista aiemmista haavoittuvuuksista, jotka Googlen tekoälyassistentti Bard oli koonnut. Tämän seurauksena tieto näytti uudelta ja merkitykselliseltä, eikä sillä ollut yhteyttä todellisuuteen.
Toinen esimerkki koskee 28. joulukuuta vastaanotettua viestiä WebSocket-käsittelijän puskurin ylivuodosta, jonka lähetti käyttäjä, joka oli jo ilmoittanut haavoittuvuuksista eri projekteihin Hackeronen kautta. Menetelmänä ongelman toistamiseen raportti sisälsi yleisiä sanoja muokatun pyynnön välittämisestä, jonka arvo on suurempi kuin strcpyllä kopioitaessa käytetyn puskurin koko. Raportissa oli myös esimerkki korjauksesta (esimerkki strcpy:n korvaamisesta strncpyllä) ja linkki koodiriville ”strcpy(keyval, randstr)”, joka hakijan mukaan sisälsi virheen.
Kehittäjä tarkisti kaiken kolme kertaa eikä löytänyt ongelmia, mutta koska raportti oli kirjoitettu luottavaisesti ja sisälsi jopa korjauksen, oli tunne, että jotain puuttuu jostain. Yritys selvittää, kuinka tutkija onnistui ohittamaan strcpy-kutsua edeltävän eksplisiittisen koon tarkistuksen ja kuinka avainpuskurin koko osoittautui luetun datan kokoa pienemmäksi, johti yksityiskohtaisiin, mutta lisätietoa sisältämättömiin selityksiin. joka vain pureskeli puskurin ylivuodon ilmeisiä yleisiä syitä, jotka eivät liity tiettyyn Curl-koodiin. Vastaukset muistuttivat kommunikointia tekoälyassistentin kanssa, ja viettäessään puoli päivää turhiin yrityksiin selvittää tarkalleen, miten ongelma ilmenee, kehittäjä oli lopulta vakuuttunut siitä, että haavoittuvuutta ei todellisuudessa ollut.
Lähde: opennet.ru