Prima di procedere
Il panorama della cybersicurezza globale vive di un equilibrio precario tra le grandi aziende tecnologiche e la comunità dei ricercatori indipendenti. Recentemente, il colosso statunitense AMD è finito al centro di una controversia che mette in discussione l'efficacia e l'etica dei programmi di bug bounty. La vicenda ha inizio nel mese di febbraio, quando un esperto di sicurezza informatica noto come Paul ha identificato una vulnerabilità strutturale nel sistema di distribuzione degli aggiornamenti software della compagnia. La falla, se sfruttata, avrebbe permesso ad attori malevoli di eseguire attacchi di tipo Man-in-the-Middle (MITM), garantendo ai pirati informatici la possibilità di iniettare codice arbitrario e ottenere l'esecuzione remota di istruzioni dannose sui sistemi degli utenti finali, compromettendo l'integrità di migliaia di macchine basate su architettura Ryzen.
Nonostante la gravità della segnalazione, AMD ha preso una decisione che ha scosso la comunità degli ethical hacker: il rifiuto categorico di corrispondere la ricompensa prevista di 10.000 dollari. La motivazione addotta dalla multinazionale di Santa Clara risiede nelle clausole restrittive della propria politica di sicurezza, secondo cui gli attacchi basati sull'intercettazione dei dati in transito, come i MITM, non rientrerebbero nel perimetro delle casistiche premiabili. Questo tecnicismo legale ha sollevato un polverone, poiché la conseguenza ultima del bug segnalato da Paul non era una semplice intercettazione di informazioni, ma il pieno controllo del sistema tramite Remote Code Execution (RCE), una delle minacce più temute nell'attuale ecosistema digitale del 2026.
Il rapporto tra il ricercatore e l'azienda è stato caratterizzato da una collaborazione che, col senno di poi, appare sbilanciata. Seguendo le linee guida del responsible disclosure, Paul ha inizialmente accettato di rimuovere ogni riferimento tecnico dal proprio blog personale su richiesta esplicita di AMD. L'azienda aveva promesso in cambio il riconoscimento ufficiale della scoperta, la registrazione di un numero CVE (Common Vulnerabilities and Exposures) e il rilascio di una patch correttiva. Tuttavia, il processo si è rivelato più tortuoso del previsto. Sebbene la soluzione tecnica sembrasse banale, ovvero il passaggio dal protocollo non criptato HTTP al sicuro HTTPS per il download dei pacchetti, AMD ha richiesto diversi rinvii dell'embargo informativo, prolungando l'esposizione al rischio per gli utenti.
Secondo le comunicazioni ufficiali intercorse tra le parti, il problema non riguardava esclusivamente l'utility Ryzen Master, ma si estendeva a una suite più ampia di strumenti software, rendendo necessaria una revisione capillare del codice di aggiornamento automatico. Questo ha portato a superare ampiamente la finestra standard di 90 giorni solitamente concessa dai ricercatori prima della pubblicazione dei dettagli. Solo dopo ben 124 giorni di attesa, precisamente il 9 giugno, l'aggiornamento definitivo è stato reso disponibile al pubblico. Durante questo lungo intervallo, milioni di utenti sono rimasti potenzialmente esposti a un rischio che la stessa AMD ha ammesso essere complesso da gestire, pur rifiutandosi di considerare la falla degna di un incentivo economico per chi l'aveva effettivamente scovata e neutralizzata.
Un ulteriore elemento di critica emerso dopo l'analisi della patch riguarda la qualità del rimedio implementato. Paul ha notato che, sebbene il canale di comunicazione sia ora protetto dalla crittografia TLS, la verifica dell'integrità dei file scaricati continua a fare affidamento sull'algoritmo di hashing CRC32. Quest'ultimo è considerato obsoleto e non sicuro dal punto di vista crittografico dalla comunità scientifica internazionale, poiché vulnerabile a collisioni intenzionali che potrebbero permettere a un attaccante sofisticato di bypassare i controlli anche sotto HTTPS. Questa scelta tecnica suggerisce una certa fretta o una sottovalutazione delle moderne tecniche di attacco da parte dei team di sviluppo interni alla compagnia.
La vicenda assume contorni quasi surreali se si considera una segnalazione apparsa sulla piattaforma Reddit da parte di un utente esperto. Secondo quanto riportato, la vulnerabilità scoperta da Paul sarebbe stata, ironicamente, protetta da un altro errore di programmazione interno ad AMD: il frammento di codice vulnerabile nel sistema di auto-aggiornamento non veniva effettivamente richiamato dall'applicazione principale. In sostanza, il sistema incaricato di aggiornare il software non funzionava correttamente, costringendo gli utenti a procedere con installazioni manuali e, paradossalmente, rendendo inefficace il tentativo di sfruttare la falla tramite MITM. Questo paradosso software non diminuisce però il merito del ricercatore, che ha evidenziato una lacuna che avrebbe potuto avere conseguenze disastrose se il codice fosse stato corretto in altre sue parti senza implementare la sicurezza necessaria.
In conclusione, il caso AMD mette in luce una problematica sistemica nell'industria dei semiconduttori. Mentre le minacce informatiche diventano sempre più sofisticate, la tendenza delle aziende a utilizzare clausole di esclusione nei programmi di bug bounty rischia di allontanare i talenti della sicurezza, spingendoli verso mercati meno etici. Per AMD, il risparmio immediato di 10.000 dollari potrebbe tradursi in un danno d'immagine molto più costoso e in una perdita di fiducia da parte di coloro che vigilano sull'integrità dei nostri dispositivi. La trasparenza e la giusta remunerazione non dovrebbero essere viste come un costo, ma come un investimento fondamentale per la resilienza digitale di un'azienda leader globale.
