Un nuovo progetto spera di rafforzare la sicurezza di V8, una parte del browser Chrome di cui la maggior parte degli utenti non è a conoscenza ma che gli hacker vedono sempre più come un obiettivo interessante.
JavaScript fa girare il web e quest'anno Google ha dovuto correggere diversi difetti zero-day o precedentemente sconosciuti nel motore JavaScript V8 di Chrome. Ad aprile, Google ha ammesso un bug di alta gravità in V8 tracciato mentre CVE-2021-21224 veniva sfruttato in natura.
Chrome ha oltre due miliardi di utenti, quindi quando gli exploit zero-day colpiscono Chrome, è un grosso problema. V8, un progetto Google open source, è un potente motore JavaScript per Chrome che ha aiutato a far progredire il web e le applicazioni web. V8 alimenta anche il runtime lato server Node.js.
Ora Samuel Groß, un membro del team di ricercatori sulla sicurezza di Google Project Zero, ha dettagliato una proposta sandbox V8 per aiutare a proteggere la sua memoria da bug più cattivi nel motore utilizzando macchine virtuali e tecnologie sandbox.
“I bug V8 in genere consentono la costruzione di exploit insolitamente potenti. Inoltre, è improbabile che questi bug vengano mitigati da linguaggi sicuri per la memoria o imminenti funzionalità di sicurezza assistite da hardware come MTE o CFI”, spiega Groß, riferendosi a tecnologie di sicurezza come Microsoft's Control integrità del flusso (CFI) e tecnologie di imposizione del flusso di controllo (CET) di Intel.
“Di conseguenza, V8 è particolarmente attraente per gli aggressori del mondo reale.”
I commenti di Gross suggeriscono che anche l'adozione di un linguaggio sicuro per la memoria come Rust, che Google ha adottato per i nuovi Codice Android: non risolverebbe immediatamente i problemi di sicurezza affrontati da V8, che è scritto in C++.
Delinea anche gli ampi obiettivi di progettazione ma, segnalando le dimensioni del progetto, sottolinea che questo progetto sandbox è agli inizi e che ci sono alcuni grossi ostacoli da superare. Ma V8 è un progetto open source guidato da Google e dato che V8 è stata la fonte di vulnerabilità di sicurezza in Chrome, c'è una possibilità che il membro della proposta di GPZ possa superare la linea.
I problemi riguardano il modo in cui il software del browser interagisce con l'hardware al di fuori del sistema operativo e mira a impedire che futuri difetti in V8 danneggino la memoria di un computer al di fuori dell'heap V8. Ciò consentirebbe a un utente malintenzionato di eseguire codice dannoso.
Una considerazione per le protezioni di sicurezza aggiuntive per V8 è l'impatto sulle prestazioni dell'hardware. Groß stima che la sua proposta causerebbe un sovraccarico di circa “l'1% complessivo sui carichi di lavoro del mondo reale”.
Groß spiega il problema con V8 che deriva dai compilatori JIT che possono essere utilizzati per indurre una macchina a emettere codice macchina che danneggia la memoria in fase di esecuzione.
“Molte vulnerabilità V8 sfruttate dagli aggressori del mondo reale sono effettivamente vulnerabilità di 2° ordine: la causa principale è spesso un problema logico in uno dei compilatori JIT, che può quindi essere sfruttato per generare codice macchina vulnerabile (ad esempio codice a cui manca un runtime controllo di sicurezza). Il codice generato può a sua volta essere sfruttato per causare il danneggiamento della memoria in fase di esecuzione.”
Evidenzia anche le carenze delle ultime tecnologie di sicurezza, comprese le mitigazioni basate sull'hardware, che renderanno V8 un obiettivo attraente per gli anni a venire ed è per questo che V8 potrebbe aver bisogno di un approccio sandbox. Questi includono:
L'attaccante ha una grande quantità di controllo sulla primitiva di corruzione della memoria e spesso può trasformare questi bug in exploit altamente affidabili e veloci
I linguaggi sicuri per la memoria non proteggeranno da questi problemi poiché sono fondamentalmente bug logici
A causa dei canali laterali della CPU e della potenza delle vulnerabilità V8, le funzionalità di sicurezza hardware imminenti come l'etichettatura della memoria saranno probabilmente aggirabili per la maggior parte del tempo
Nonostante sminuisca la probabilità che il nuovo sandbox V8 venga effettivamente adottato, il ricercatore sembra ottimista riguardo alle sue prospettive di svolgere il lavoro previsto richiedendo a un aggressore di concatenare due vulnerabilità separate per eseguire il codice di loro scelta.
“Con questa sandbox, si presume che gli aggressori siano in grado di corrompere la memoria all'interno della gabbia della memoria virtuale in modo arbitrario e da più thread, e ora richiederanno un'ulteriore vulnerabilità per corrompere la memoria al di fuori di essa, e quindi per eseguire codice arbitrario”, ha scritto.
Argomenti correlati:
Security TV Data Management CXO Data Center 