I ricercatori dell'Università di Cambridge hanno pubblicato una tecnica di sostituzione inosservata di codice dannoso nei testi sorgente sottoposti a revisione. Il metodo di attacco elaborato (CVE-2021-42574) è stato presentato con il nome Trojan Source e si basa sulla formazione di un testo che appare diverso per il compilatore/interpretatore e per l'essere umano che visualizza il codice. Esempi di applicazione del metodo sono stati dimostrati per diversi compilatori e interpretatori forniti per i linguaggi C, C++ (gcc e clang), C#, JavaScript (Node.js), Java (OpenJDK 16), Rust, Go e Python.
Il metodo si basa sull'uso di simboli Unicode speciali nei commenti al codice, che modificano l'ordine di visualizzazione del testo bidirezionale. Con tali simboli di controllo, alcune parti del testo possono essere visualizzate da sinistra a destra mentre altre da destra a sinistra. Nella pratica quotidiana, tali simboli di controllo possono essere utilizzati, ad esempio, per inserire righe in ebraico o arabo in un file di codice. Tuttavia, combinando righe con direzioni del testo diverse in una riga, tramite i simboli indicati, blocchi di testo visualizzati da destra a sinistra possono sovrapporsi al testo normale visualizzato da sinistra a destra.
Utilizzando questo metodo nel codice è possibile aggiungere una costruzione dannosa, ma poi rendere invisibile il testo con tale costruzione durante la visualizzazione del codice, aggiungendo in un commento successivo o all'interno di un letterale caratteri mostrati da destra a sinistra, che porteranno alla sovrapposizione sulla parte malevola di simboli completamente diversi. Tale codice rimarrà semanticamente corretto, ma sarà interpretato e visualizzato in modo diverso.
Durante la revisione del codice, lo sviluppatore si troverà di fronte all'ordine visivo di visualizzazione dei caratteri e vedrà in un editor di testo moderno, interfaccia web o IDE un commento non sospetto, ma il compilatore e l'interpretatore utilizzeranno l'ordine logico dei caratteri e tratteranno l'inserimento dannoso come tale, ignorando il testo bidirezionale nel commento. Diversi editor di codice popolari (VS Code, Emacs, Atom), così come le interfacce per la visualizzazione del codice nei repository (GitHub, Gitlab, BitBucket e tutti i prodotti Atlassian), sono vulnerabili a questo problema.
Vengono evidenziati diversi modi di utilizzare il metodo per attuare azioni dannose: aggiunta di un'espressione nascosta «return», che porta a una terminazione anticipata dell'esecuzione della funzione; racchiudere in commenti espressioni normalmente visibili come costrutti attivi (ad esempio, per disattivare controlli importanti); assegnazione di altri valori stringa che portano a errori nei controlli delle stringhe.
Ad esempio, un attaccante potrebbe suggerire una modifica che include la riga: if access_level != «user{U+202E} {U+2066}// Check if admin{U+2069} {U+2066}» {
che verrà visualizzata nell'interfaccia per la revisione come if access_level != «user» { // Check if admin
Inoltre, è stata proposta un'altra variante di attacco (CVE-2021-42694), collegata all'uso di omoglyphs, simboli simili nel contesto visivo ma diversi nel significato e con codici unicode diversi (ad esempio, il simbolo «ɑ» ricorda «a», «ɡ» — «g», «ɩ» — «l»). Tali simboli possono essere utilizzati in alcuni linguaggi nei nomi delle funzioni e delle variabili per confondere gli sviluppatori. Ad esempio, possono essere definite due funzioni con nomi indistinguibili che svolgono azioni diverse. Senza un'analisi dettagliata, non è immediato comprendere quale di queste due funzioni venga richiamata in un determinato punto.
Come misura di protezione, si raccomanda di implementare nei compilatori, interpreti e strumenti di build che supportano caratteri Unicode, l'uscita di un errore o un avviso in presenza di caratteri di controllo dispari nei commenti, nelle stringhe letterali o negli identificatori, che alterano la direzione dell'output (U+202A, U+202B, U+202C, U+202D, U+202E, U+2066, U+2067, U+2068, U+2069, U+061C, U+200E e U+200F). Tali simboli dovrebbero essere esplicitamente vietati anche nelle specifiche dei linguaggi di programmazione e dovrebbero essere presi in considerazione nei codici editor e nelle interfacce per lavorare con i repository.
Aggiunta 1: Le correzioni per l'eliminazione della vulnerabilità sono state preparate per GCC, LLVM/Clang, Rust, Go, Python e binutils. Anche GitHub, Bitbucket e Jira hanno risolto il problema. È in fase di preparazione una correzione per GitLab. Per identificare il codice problematico, si suggerisce di utilizzare il comando: grep -r $'[\u061C\u200E\u200F\u202A\u202B\u202C\u202D\u202E\u2066\u2067\u2068\u2069]' /path/to/source
Supplemento 2: Russ Cox, uno degli sviluppatori del sistema operativo Plan 9 e del linguaggio di programmazione Go, ha criticato l'eccessiva attenzione rivolta al metodo di attacco descritto, che è conosciuto da tempo (Go, Rust, C++, Ruby) e non è mai stato preso sul serio. Secondo Cox, il problema riguarda principalmente la correttezza della visualizzazione delle informazioni negli editor di codice e nelle interfacce web, e può essere risolto utilizzando strumenti adeguati e analizzatori di codice durante la revisione. Pertanto, anziché attirare l'attenzione su attacchi speculativi, sarebbe più corretto concentrarsi sul miglioramento dei processi di revisione del codice e delle dipendenze.
Russ Cox ritiene inoltre che i compilatori non siano il luogo giusto per risolvere il problema, poiché vietare simboli pericolosi a livello di compilazione lascia un ampio spettro di strumenti in cui l'uso di tali simboli rimane consentito, come sistemi di build, assemblatori, gestori di pacchetti e vari parser di configurazione e dati. Ad esempio, il progetto Rust ha vietato l'elaborazione del codice LTR/RTL nel compilatore, ma non ha aggiunto correttivi al gestore di pacchetti Cargo, il che consente di effettuare un attacco simile attraverso il file Cargo.toml. Analogamente, file come BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml e requirements.txt possono diventare fonti di attacco.
Fonte: opennet.ru
