Riepilogo Tecnico: Attacchi Backdoor Attivati dall'Ottimizzazione su LLM

1. Enunciato del Problema

Il documento affronta una vulnerabilità di sicurezza precedentemente trascurata nella pipeline di distribuzione dei Large Language Model (LLM): i backdoor attivati dall'ottimizzazione. Sebbene le tecniche di ottimizzazione dell'inferenza, in particolare la compilazione del modello (ad es. torch.compile), siano standard per il scaling degli LLM, esse si basano sull'assunzione che la compilazione preservi l'equivalenza semantica, trattando eventuali differenze numeriche residue come innocui artefatti in virgola mobile.

Gli autori sfidano tale assunzione, dimostrando che le minime discrepanze numeriche introdotte dai compilatori — derivanti dalla fusione degli operatori, dalla pianificazione dei kernel e dalla riasociazione in virgola mobile — possono essere deliberatamente trasformate in armi. A differenza dei backdoor tradizionali che si attivano tramite specifici pattern di input (trigger) o manomissione dei pesi, questi attacchi sono innescati esclusivamente dall'atto della compilazione. Un modello può comportarsi in modo benigno sotto esecuzione standard "eager" (superando audit di sicurezza e red-teaming) ma emettere output malevoli quando compilato per il deployment in produzione. Ciò crea una superficie di attacco subdola in cui l'ambiente di esecuzione stesso funge da trigger.

2. Metodologia

Gli autori propongono un framework di attacco unificato composto da due strategie complementari progettate per sfruttare la fragilità numerica dell'esecuzione compilata senza modificare il compilatore, l'hardware o la pipeline di inferenza. Entrambe le strategie comportano la modifica dei pesi del modello (ad es. tramite adattatori LoRA) per forzare il modello in un regime sensibile alle perturbazioni indotte dal compilatore.

A. Attacco I: Modellazione dei Confini Specifici per Input (ISBS)

• Obiettivo: Creare un backdoor senza trigger per input specifici e predefiniti.
• Meccanismo: L'attaccante utilizza una modifica leggera dei parametri basata su LoRA per spingere la distribuzione dei logit di un input target verso il confine decisionale.
• Processo:
  1. Ottimizzare i parametri LoRA sotto esecuzione eager per minimizzare il divario tra il logit del token corretto e quello del token malevolo.
  2. Ciò posiziona l'input a un confine "sensibile alla compilazione" dove la minuscola deviazione numerica introdotta dal compilatore è sufficiente a invertire la previsione arg max.
• Ambito: Mirato; richiede ottimizzazione separata per ogni singolo input specifico.

B. Attacco II: Backdoor Attivato dalla Compilazione (CTB)

• Obiettivo: Creare un backdoor universale che si attivi su input arbitrari quando compilato.
• Meccanismo: Questa strategia opera a livello di attivazione, utilizzando un token trigger continuo e un termine di bias calibrato.
• Processo (Tre Fasi):
  1. Profilazione della Divergenza e Ottimizzazione del Trigger: Identificare un "livello critico" e dimensioni specifiche che mostrano la massima divergenza numerica tra esecuzione eager e compilata. Ottimizzare un embedding di trigger continuo per produrre attivazioni strettamente raggruppate in queste dimensioni sotto esecuzione eager.
  2. Costruzione del Bias Multidimensionale: Iniettare un termine di bias che sottrae la media di queste attivazioni raggruppate. Sotto esecuzione eager, ciò collassa le attivazioni vicino allo zero (soppresso da non linearità come SiLU). Sotto esecuzione compilata, spostamenti numerici sistematici spostano queste attivazioni dallo zero, creando un residuo non nullo.
  3. Fine-Tuning Condizionato alla Divergenza: Affinare i livelli superiori del modello per mappare questa divergenza residua (presente solo in modalità compilata con il trigger) verso un output malevolo, mantenendo al contempo un comportamento corretto per input puliti e input attivati in modalità eager.

3. Contributi Chiave

1. Nuova Superficie di Attacco: Il documento è il primo a identificare e definire la compilazione dell'inferenza come una superficie di attacco distinta per gli LLM, introducendo il concetto di backdoor attivati dall'ottimizzazione.
2. Framework Unificato: Propone un framework (ISBS e CTB) che si generalizza su più backend di compilazione (Inductor, CUDAGraphs) senza richiedere modifiche al compilatore o all'hardware.
3. Analisi Causale e Difesa: Gli autori conducono un'analisi causale per localizzare la fonte delle vulnerabilità (principalmente i blocchi Feed-Forward Network) e valutano sistematicamente quattro difese pratiche: Perturbazione dell'Input, Variazione della Dimensione del Batch, Cambio di Precisione e Ulteriore Fine-Tuning.

4. Risultati Sperimentali

Il framework è stato valutato su quattro LLM open-source mainstream (Llama-3.2-1B/3B, Qwen2.5-1.5B/3B) attraverso quattro compiti diversificati: Selezione degli strumenti per Agenti, Sicurezza dell'IA Embodied, QA Medica e Classificazione del Sentimento (SST).

• Tasso di Successo dell'Attacco (ASR):
  • Sotto il backend Inductor, l'attacco CTB ha raggiunto un ASR medio di ~90%, con picchi del 100% su diverse combinazioni modello-compito.
  • Sotto CUDAGraphs, l'ASR è stato in media di ~74%, con alcune variazioni dovute a pattern specifici del backend di fusione dei kernel.
• Furtività e Utilità:
  • Accuratezza Pulita: Preservata a quasi 100% sia sotto esecuzione eager che compilata per input puliti.
  • Furtività: Gli input attivati hanno mantenuto un'alta accuratezza (superando ispezioni di sicurezza) sotto esecuzione eager (ad es. media del 93,3% per Inductor), garantendo che il backdoor rimanga non rilevato durante gli audit standard pre-deployment.
• Trasferibilità: Gli attacchi ottimizzati su Inductor hanno mostrato una parziale trasferibilità a CUDAGraphs, sebbene le prestazioni siano variate in base all'architettura del modello (i modelli Qwen si sono generalizzati meglio dei modelli Llama nei test cross-backend).

5. Significato e Affermazioni

Il documento afferma che l'intersezione tra ottimizzazione e sicurezza rappresenta una vulnerabilità critica, precedentemente ignorata, nell'ecosistema degli LLM.

• Impatto Reale: Gli autori sostengono che questi attacchi siano particolarmente pericolosi in settori ad alto rischio dove la compilazione è fortemente affidata per le prestazioni, come il supporto alle decisioni mediche, il controllo robotico e i flussi di lavoro degli agenti. Minime variazioni nell'output possono tradursi in danni clinici, economici o fisici.
• Limiti delle Difese Attuali: La ricerca sulla sicurezza esistente si concentra su trigger di input o avvelenamento dei pesi. Il documento evidenzia che le valutazioni di sicurezza standard (eseguite senza compilazione) sono insufficienti per rilevare queste minacce, poiché il comportamento malevolo è condizionato all'ambiente di deployment.
• Appello all'Azione: Gli autori concludono che lo stack di ottimizzazione deve essere trattato come parte del perimetro di sicurezza degli LLM. Sostengono l'estensione delle valutazioni di sicurezza per coprire l'intera pipeline di ottimizzazione dell'inferenza e suggeriscono che un leggero fine-tuning e la validazione a doppio kernel (confrontando output eager vs. compilati) siano strategie di mitigazione pratiche.

Il lavoro non afferma di rompere universalmente tutti gli LLM, ma dimostra che gli effetti collaterali numerici "innocui" dei compilatori moderni possono essere sistematicamente ingegnerizzati in trigger affidabili e controllabili per comportamenti malevoli.