IA utilitzada per detectar problemes de seguretat
Fa pocs dies, Daniel Stenberg (l'autor de Curl) va donar a conèixer al vostre bloc, una publicació en la qual expressa no només com una crítica l'ús d'eines d'intel·ligència artificial, sinó en forma de reclam, les molèsties que això genera a ell i al seu equip, els informes de seguretat generats per les eines d intel·ligència artificial.
I és que en la publicació, Daniel Stenberg esmenta que durant molts anys el procés de verificar tots els informes i descartar entre els problemes de seguretat “escombraries” i “reals”, no era una cosa que suposés un esforç addicional, doncs esmenta que «els informes escombraries normalment també han estat molt fàcils i ràpids de detectar i descartar».
Amb el recent auge de la intel·ligència artificial, s'han revolucionat moltes tasques que anteriorment requerien moltes hores d'intervenció humana. Entre els casos més esmentats en aquest bloc, hem abordat els temes de IA dedicades a la programació, generació d'imatges, edició de vídeo, com ChatGPT, Copilot, Bard, entre d'altres.
En l'àmbit específic de la programació, Copilot va generar nombroses crítiques, i la principal preocupació va ser la possibilitat d'enfrontar demandes legals. No obstant això, a l'altre extrem de la balança, la intervenció de la intel·ligència artificial ha transformat significativament diverses àrees. Per exemple, en la detecció d'errors i problemes de seguretat al codi, les IAs han tingut un paper crucial. Moltes persones han adoptat aquestes eines per identificar possibles errors i vulnerabilitats al codi, sovint participant en programes de recompenses per la detecció de problemes de seguretat.
Curl no va escapar d'aquesta tendència, i Daniel Stenberg va expressar al seu bloc que, després de diversos mesos de contenir la seva opinió, finalment va explotar desacord amb l'ús d'eines d'intel·ligència artificial. La raó darrere de la seva frustració va ser la quantitat creixent d'informes «escombraries» generats per l'ús d'aquestes eines.
A la publicació, es destaca que aquests informes tenen una aparença detallada, estan redactats en un llenguatge normal i semblen ser d'alta qualitat. No obstant això, sense una anàlisi acurada, resulten ser enganyosos, ja que reemplacen problemes reals amb contingut de baixa qualitat que aparenta ser valuós.
El Projecte Curl, que ofereix recompenses per la identificació de noves vulnerabilitats, ha rebut un total de 415 informes sobre possibles problemes. D'aquest conjunt, només 64 van ser confirmats com a vulnerabilitats reals, 77 van descriure errors no relacionats amb la seguretat i, sorprenentment, 274 (66%) no contenien informació útil, consumint el temps dels desenvolupadors que podria haver-se dedicat a alguna cosa útil.
Els desenvolupadors es veuen obligats a perdre molt de temps analitzant informes inútils i verificant diverses vegades la informació continguda allà, ja que la qualitat externa del disseny crea confiança addicional en la informació i hi ha la sensació que el desenvolupador no va entendre alguna cosa.
D'altra banda, generar un informe d'aquest tipus requereix un esforç mínim per part del sol·licitant, que no es molesta a comprovar si hi ha un problema real, sinó que simplement copia a cegues les dades rebudes dels assistents d'IA, esperant tenir sort a la lluita per rebre una recompensa.
Daniel Stenberg, comparteix dos exemples d'aquest tipus d'informes escombraries:
- En el primer cas, just abans de la divulgació planificada de la informació sobre una vulnerabilitat crítica a l'octubre, es va rebre un informe a través de HackerOne indicant que ja hi havia un pegat públic per resoldre el problema. Tot i això, l'informe va resultar ser «fals», ja que contenia dades sobre problemes similars i fragments d'informació detallada sobre vulnerabilitats passades, compilats per l'assistent d'intel·ligència artificial de Google, Bard. Tot i que la informació semblava nova i rellevant, no tenia connexió amb la realitat.
- En el segon cas, es va rebre un informe sobre un desbordament de memòria intermèdia en el maneig de WebSocket. Aquest informe provenia d'un usuari que ja havia informat de vulnerabilitats a diversos projectes a través de HackerOne. Per reproduir el problema, l'informe proporcionava instruccions generals sobre com enviar una sol·licitud modificada i un exemple de correcció.
Tot i verificar detalladament tres vegades el codi, el desenvolupador no va trobar cap problema. No obstant això, atès que l'informe estava redactat de manera que generava “certa” confiança i fins i tot presentava una solució proposada, persistia la sensació que alguna cosa no encaixava.
En un esforç per aclarir com l'usuari va aconseguir eludir la verificació de mida, s'esmenta que les explicacions no contenien informació addicional i només analitzaven causes comunes òbvies de desbordament de memòria intermèdia no relacionades amb el codi de Curl. Les respostes recordaven la comunicació amb un assistent d'IA, i després d'intents inútils per descobrir exactament com es manifestava el problema, Daniel Stenberg finalment es va convèncer que en realitat no existia cap vulnerabilitat i va tancar el tema com a no “aplicable”.
Finalment si estàs interessat a poder conèixer més sobre això, pots consultar els detalls al següent enllaç.