I ricercatori dell'Università di Cambridge hanno pubblicato una tecnica per inserire silenziosamente codice dannoso nel codice sorgente sottoposto a revisione paritaria. Il metodo di attacco preparato (CVE-2021-42574) si presenta sotto il nome Trojan Source e si basa sulla formazione di un testo che appare diverso per il compilatore/interprete e per la persona che visualizza il codice. Vengono dimostrati esempi del metodo per vari compilatori e interpreti forniti per C, C++ (gcc e clang), C#, JavaScript (Node.js), Java (OpenJDK 16), Rust, Go e Python.
Il metodo si basa sull'utilizzo di caratteri Unicode speciali nei commenti del codice che modificano l'ordine di visualizzazione del testo bidirezionale. Con l'aiuto di tali caratteri di controllo, alcune parti del testo possono essere visualizzate da sinistra a destra, mentre altre da destra a sinistra. Nella pratica quotidiana tali caratteri di controllo possono essere utilizzati, ad esempio, per inserire righe di codice in ebraico o arabo in un file. Ma se si combinano righe con direzioni di testo diverse in un'unica riga, utilizzando i caratteri specificati, i passaggi di testo visualizzati da destra a sinistra possono sovrapporsi al testo normale esistente visualizzato da sinistra a destra.
Usando questo metodo, puoi aggiungere un costrutto dannoso al codice, ma poi rendere invisibile il testo con questo costrutto durante la visualizzazione del codice, aggiungendo nel commento seguente o all'interno dei caratteri letterali mostrati da destra a sinistra, il che porterà a completamente diversi caratteri vengono sovrapposti all'inserimento dannoso. Tale codice rimarrà semanticamente corretto, ma verrà interpretato e visualizzato in modo diverso.
Durante la revisione del codice, uno sviluppatore si confronterà con l'ordine visivo dei caratteri e vedrà un commento non sospetto in un moderno editor di testo, interfaccia web o IDE, ma il compilatore e l'interprete utilizzeranno l'ordine logico dei caratteri e lo faranno elaborare l'inserimento dannoso così com'è, senza prestare attenzione al testo bidirezionale nei commenti. Il problema riguarda diversi editor di codice popolari (VS Code, Emacs, Atom), nonché le interfacce per la visualizzazione del codice nei repository (GitHub, Gitlab, BitBucket e tutti i prodotti Atlassian).
Esistono diversi modi per utilizzare il metodo per implementare azioni dannose: aggiungere un'espressione nascosta di "ritorno", che porta al completamento della funzione in anticipo; commentare espressioni che normalmente sarebbero visibili come costrutti validi (ad esempio, per disabilitare controlli importanti); assegnare altri valori di stringa che portano a errori di convalida della stringa.
Ad esempio, un utente malintenzionato potrebbe proporre una modifica che includa la riga: if access_level != "user{U+202E} {U+2066}// Controlla se admin{U+2069} {U+2066}" {
che verrà visualizzato nell'interfaccia di revisione come se access_level != “user” { // Controlla se admin
Inoltre, è stata proposta un’altra variante di attacco (CVE-2021-42694), associata all’uso di omoglifi, caratteri simili nell’aspetto, ma diversi nel significato e con codici unicode diversi (ad esempio, il carattere “ɑ” assomiglia a “ a”, “ɡ” - “g”, “ɩ” - “l”). Caratteri simili possono essere utilizzati in alcune lingue nei nomi di funzioni e variabili per fuorviare gli sviluppatori. Ad esempio, è possibile definire due funzioni con nomi indistinguibili che eseguono azioni diverse. Senza un'analisi dettagliata, non è immediatamente chiaro quale di queste due funzioni venga richiamata in un luogo specifico.
Come misura di sicurezza, si consiglia che compilatori, interpreti e strumenti di assemblaggio che supportano i caratteri Unicode visualizzino un errore o un avviso se sono presenti caratteri di controllo non accoppiati in commenti, valori letterali di stringa o identificatori che modificano 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 caratteri dovrebbero anche essere esplicitamente vietati nelle specifiche del linguaggio di programmazione e dovrebbero essere rispettati negli editor di codice e nelle interfacce dei repository.
Addendum 1: Sono state preparate patch di vulnerabilità per GCC, LLVM/Clang, Rust, Go, Python e binutils. Anche GitHub, Bitbucket e Jira hanno risolto il problema. È in corso una correzione per GitLab. Per identificare il codice problematico, si consiglia di utilizzare il comando: grep -r $'[\u061C\u200E\u200F\u202A\u202B\u202C\u202D\u202E\u2066\u2067\u2068\u2069]' /path/to/ fonte
Addendum 2: Russ Cox, uno degli sviluppatori del sistema operativo Plan 9 e del linguaggio di programmazione Go, ha criticato l'eccessiva attenzione al metodo di attacco descritto, noto da tempo (Go, Rust, C++, Ruby) e non preso sul serio . Secondo Cox il problema riguarda soprattutto la corretta visualizzazione delle informazioni negli editor di codice e nelle interfacce web, che può essere risolto utilizzando gli strumenti e gli analizzatori di codice corretti durante la revisione. Pertanto, invece di attirare l’attenzione su attacchi speculativi, sarebbe più appropriato concentrarsi sul miglioramento dei processi di revisione del codice e delle dipendenze.
Ras Cox ritiene inoltre che i compilatori non siano il posto giusto per risolvere il problema, poiché vietando i simboli pericolosi a livello di compilatore, rimane un enorme strato di strumenti in cui l'uso di questi simboli rimane accettabile, come sistemi di compilazione, assemblatori, gestori di pacchetti e vari parser e dati di configurazione. Ad esempio, viene fornito il progetto Rust, che ha vietato l'elaborazione del codice LTR/RTL nel compilatore, ma non ha aggiunto una correzione al gestore di pacchetti Cargo, che consente un attacco simile tramite il file Cargo.toml. Allo stesso modo, file come BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml e requisiti.txt possono diventare fonti di attacchi.
Fonte: opennet.ru