Anthropic svela Mythos e Project Glasswing: una vulnerabilità che viola la Same-Origin Policy

Quando Anthropic ha presentato Mythos e Project Glasswing, la reazione è stata immediata e polarizzata. Alcuni hanno liquidato il tutto come marketing basato sulla paura, mentre altri lo hanno considerato un cambiamento credibile nel panorama delle minacce. Probabilmente la verità sta nel mezzo. Ho voluto verificare di persona e, avendo recentemente ottenuto l'accesso al programma Trusted Access for Cyber di OpenAI, ho deciso di testarlo.

GPT-5.4 ha identificato i bug e ha aiutato a assemblare una catena di exploit funzionante, ma non si è trattato di un semplice prompt del tipo "costruiscimi un exploit". Guidare il modello ha richiesto conoscenze di dominio, indagini iterative e la capacità di riconoscere quali percorsi fossero effettivamente sfruttabili.

Nei browser moderni come Safari, lo sfruttamento è meno legato alla ricerca di bug e più alla scoperta di bug che abbiano ancora un impatto significativo dopo più livelli di difesa.

Il bug che viola la Same-Origin Policy

Il bug di cui parlerò oggi rientra in una categoria più interessante. Il bug in sé sembrava contenuto e, in molti modi, lo era. Non forniva un percorso per l'esecuzione remota di codice o la fuga dalla sandbox. Ciò che faceva, invece, era attraversare un confine diverso: violava la Same-Origin Policy.

Se si visitava una pagina maliziosa da qualsiasi dispositivo Apple, questa poteva leggere dati cross-origin autenticati da altri siti utilizzati, inclusi token di accesso e altre informazioni sensibili, rendendo banale il takeover di account. Il video qui sotto mostra la prova di concetto inviata ad Apple, dimostrando la perdita di dati sensibili sia da Apple Connect che dagli endpoint iCloud/Apple ID. Sebbene questa dimostrazione si concentri sui servizi Apple, il problema colpisce tutti i siti web. Questo significa che visitando un sito web malizioso, i dati sensibili di altri domini rischiano di essere divulgati.

La Sandbox Russian Doll

Lo sfruttamento del browser nel 2026 è molto simile a rimanere intrappolati in una bambola russa. Si inizia nella bambola più piccola e ogni volta che si fugge da un livello, ci si ritrova ancora intrappolati in un altro. Trovare un bug a basso livello di memoria non è la stessa cosa che trovare un exploit. La maggior parte di questi bug muoiono nel divario tra "è avvenuta la corruzione della memoria" e "qualcosa di significativo ha attraversato un confine di sicurezza".

All'esterno c'è il modello di processo del browser. Anche se il codice del renderer va storto, il browser cerca di mantenere quel danno all'interno del processo di contenuto web. All'interno di questo, c'è il modello di sicurezza web: Same-Origin Policy, CORS, risposte opache, ambito dei cookie e modalità di credenziali. Anche se una pagina può scatenare una richiesta cross-origin, il renderer, e in particolare il [Gigacage](https://phakeobj.netlify.app/posts/gigacage/), non dovrebbe essere in grado di accedere ai byte della risposta. Giusto?

Il Bug

Il bug originale risiede nella logica di aggiornamento per la memoria WebAssembly ridimensionabile non condivisa. Quando una WebAssembly.Memory non condivisa cresce in modalità BoundsChecking, JavaScriptCore può sostituire il handle della memoria sottostante. Questa parte non è il bug. Il bug è ciò che accade dopo a causa del buffer ridimensionabile visibile a JavaScript restituito da memory.toResizableBuffer().

Il bug è semplice: dopo memory.grow(), WebKit aggiorna i metadati del buffer ma lascia mdata che punta alla vecchia allocazione liberata. Quindi, dopo la crescita, JavaScript può detenere un buffer il cui dimensioni riportate sono nuove, il cui handle è nuovo, ma il cui puntatore ai dati effettivi fa ancora riferimento all'allocazione Primitive Gigacage liberata. Questo si trasforma in una finestra di array tipizzati su memoria liberata.

Di per sé, questo è già un bug reale. Ma siamo ancora intrappolati all'interno del Gigacage di JavaScriptCore, effettivamente sandboxed. Senza un secondo bug per uscire nel renderer, non si incatena in qualcosa di significativo. Quello che abbiamo è un solido primitivo di prima fase, ma nessun impatto sulla sicurezza da solo.

Perché inizialmente non sembrava sfruttabile

La finestra stantia è confinata nel Primitive Gigacage, che limita immediatamente ciò che è possibile fare. Molti bersagli tipici non atterrano lì, mancano di struttura utile o non producono alcun effetto transfrontaliero. All'inizio, quindi, presentava tutti i segni di un bug che sembra promettente ma raramente arriva al traguardo:

  • causa radicata facile a livello di sorgente
  • comportamento della memoria stantia visibile
  • recupero reale
  • nessun percorso di fuga pulito

È qui che molti bug a basso livello del browser muoiono.

Il Pivot

Invece di chiedermi "come faccio a passare dalla mia vista WASM stantia a qualche stato protetto del browser?", ho iniziato a farmi una domanda migliore: "Quale codice del browser prende dati che JavaScript non è autorizzato a leggere, ma copia comunque quei dati nella memoria normale del renderer?". Perché è tutto ciò di cui ho bisogno. Non ho bisogno di rompere l'astrazione. Ho solo bisogno che il browser la rompa per me.

Questo restringe naturalmente lo spazio di ricerca ai sottosistemi che:

  • gestiscono dati cross-origin sensibili e
  • ancora allocano memoria supportata da ArrayBuffer come parte del loro pipeline interno

Questo punta direttamente al Fetch. La [Fetch API](https://developer.mozilla.org/en-US/docs/Web/API/FetchAPI/Using_Fetch) indica chiaramente che la risposta è opaca, il che significa che le intestazioni e il corpo non sono disponibili per JavaScript.

Risposte Opaque Dovrebbero Essere Opaque

Al livello dell'API, il modello Fetch qui è semplice. Se esegui una richiesta cross-origin con:

fetch(url, { mode: “no-cors”, credentials: “include” });

Il browser può inviare la richiesta, inclusi i cookie a seconda del contesto, ma JavaScript riceve una risposta opaca. Questo significa:

  • puoi detenere l'oggetto Response
  • ma non puoi leggere i byte del corpo

WebKit applica questo controllo nel posto ovvio: FetchBodyOwner::readableStream() blocca i corpi opachi tramite isBodyNullOrOpaque(). Quindi, a prima vista, tutto sembra a posto. Il corpo è nascosto. La policy è applicata. La Same-Origin Policy sopravvive un altro giorno. Tranne che non è così.

Il Comportamento di Fetch che Ha Rotto il Modale

La parte sorprendente è Response.clone(). Se FetchResponse::clone() viene chiamato mentre la risposta è ancora in caricamento, WebKit creerà internamente un flusso leggibile in modo da poter dividere il corpo tra la risposta originale e la clonazione. Questo percorso interno non applica lo stesso controllo del corpo opaco.

E una volta che accade, i byte della risposta nascosta iniziano a diventare oggetti del renderer molto reali. Questa è la parte che mi ha fatto fermare e guardare il codice sorgente, perché la discrepanza è proprio lì. Il percorso di accesso visibile dice "i corpi opachi non ottengono un flusso". Il percorso di clonazione dice "se è ancora in caricamento, crea un flusso in modo che entrambe le clonazioni possano dividerlo".

Quel secondo percorso è esattamente ciò di cui avevo bisogno. I dati fluiscono attraverso i percorsi di creazione di ArrayBuffer normali:

  • i frammenti bufferizzati passano attraverso tryCreateArrayBuffer()
  • i dati del buffer condivisi vengono copiati nelle allocazioni ordinarie di ArrayBuffer all'interno del renderer

La policy finisce per essere divisa in due:

  • l'API Fetch dice "i corpi opachi non ottengono un flusso"
  • il percorso di clonazione dice "se è ancora in caricamento, crea un flusso"

Quindi, se cloniamo una risposta opaca, otteniamo un flusso leggibile. E se leggiamo da quel flusso, otteniamo dati che non dovremmo essere in grado di leggere. Questo è il bug.

La Catena di Exploit

La catena di exploit è semplice:

  • ottenere una risposta opaca
  • clonarla
  • leggere dal flusso leggibile risultante

E questo è tutto. Ora possiamo leggere i dati che non dovremmo essere in grado di leggere. Questo è un problema serio perché significa che un sito web malizioso potrebbe leggere i dati sensibili di un altro sito web.

L'Impatto

L'impatto di questo bug è significativo. Un aggressore potrebbe utilizzare questo bug per rubare dati sensibili da altri siti web. Ad esempio, un sito web malizioso potrebbe leggere i token di accesso di un utente da un altro sito web, permettendo all'aggressore di accedere al conto dell'utente. Inoltre, questo bug potrebbe essere utilizzato per bypassare altre misure di sicurezza, come il controllo dell'origine.

La Soluzione

La soluzione a questo bug è semplice: non permettere la clonazione delle risposte opache. Questo è ciò che ha fatto WebKit. Ora, se provi a clonare una risposta opaca, otterrai un errore. Questo impedisce agli aggressori di sfruttare questo bug.

Questo bug è un esempio di come anche un piccolo errore possa avere gravi conseguenze. È importante che gli sviluppatori siano consapevoli di questi problemi e che i browser siano progettati per prevenirli. Inoltre, è fondamentale che gli utenti siano consapevoli dei rischi associati alla navigazione su siti web non sicuri.

Prospettive Future e Prevenzione

Questo caso evidenzia l'importanza di un approccio proattivo alla sicurezza nelle architetture moderne. Con l'evoluzione continua dei browser e delle tecnologie web, è cruciale che gli sviluppatori adottino pratiche di programmazione sicura e conducano test rigorosi per identificare e mitigare vulnerabilità prima che possano essere sfruttate. La collaborazione tra ricercatori di sicurezza, sviluppatori e fornitori di browser è fondamentale per garantire che tali problemi siano affrontati tempestivamente.

Implicazioni per gli Utenti

Per gli utenti, la consapevolezza dei rischi associati alla navigazione web è essenziale. Utilizzare browser aggiornati, evitare siti non sicuri e adottare misure come l'uso di password complesse e l'autenticazione a due fattori possono ridurre significativamente il rischio di essere vittime di attacchi basati su vulnerabilità come quelle descritte. Inoltre, è importante rimanere informati sulle ultime minacce e sui consigli di sicurezza forniti dagli esperti del settore.

Innovazioni Tecnologiche

Le tecnologie emergenti come l'intelligenza artificiale e il machine learning stanno rivoluzionando il campo della sicurezza informatica. Strumenti avanzati possono aiutare a identificare schemi anomali e potenziali vulnerabilità in modo più efficiente rispetto ai metodi tradizionali. Tuttavia, è necessario un equilibrio tra innovazione e sicurezza, garantendo che nuove funzionalità non introducano nuove vulnerabilità.

Collaborazione Globale

La natura globale di Internet richiede una collaborazione internazionale per affrontare le minacce alla sicurezza. Organizzazioni come l'Internet Engineering Task Force (IETF) e l'Internet Society lavorano per stabilire standard e best practice che possano essere adottati in tutto il mondo. La condivisione di informazioni e risorse tra nazioni e settori è fondamentale per creare un ecosistema web più sicuro per tutti.

Conclusione Finale

La scoperta e la risoluzione di questa vulnerabilità rappresentano un passo importante verso un web più sicuro. Tuttavia, il lavoro non finisce qui. La sicurezza informatica è un processo continuo che richiede vigilanza costante, innovazione e collaborazione. Solo attraverso sforzi collettivi possiamo sperare di proteggere i dati sensibili degli utenti e garantire un'esperienza di navigazione sicura per tutti.

Nota Editoriale e Disclaimer

Le guide e i contenuti pubblicati su GoYou sono frutto di attività di ricerca e analisi indipendente, a scopo informativo, educativo e di approfondimento.

GoYou non costituisce una testata giornalistica né un prodotto editoriale ai sensi della Legge n. 62/2001 e non svolge attività di informazione in tempo reale.

Il progetto GoYou non fornisce consulenza professionale, tecnica, legale o finanziaria e declina ogni responsabilità per l’uso improprio delle informazioni pubblicate.

Nel settore Crypto, ogni investimento comporta rischi: si invita il lettore a informarsi sempre in modo autonomo prima di assumere qualsiasi decisione.