Pochi giorni fa Rilasciati i ricercatori dell'Università di Cambridge la pubblicazione di una tecnica per sostituire sottilmente i codici codice dannoso nel codice sorgente dell'applicazione.
Il metodo di attacco lo ha preparato È già elencato sotto CVE-2021-42574 Viene chiamato Trojan Source e si basa sulla formazione di testo che appare diverso dal compilatore/interprete e dalla persona che visualizza il codice.
Informazioni su Trojan Source
Il metodo si basa sull'applicazione di caratteri Unicode speciali nei commenti del codice, che modificano l'ordine di visualizzazione del testo bidirezionale. Con l'aiuto di questi personaggi di controllo, alcune parti del testo possono essere visualizzate da sinistra a destra, mentre altre da destra a sinistra.
Nella pratica quotidiana, questi caratteri di controllo possono essere utilizzati, ad esempio, per inserire stringhe ebraiche o arabe in un file di codice. Tuttavia, se si utilizzano questi caratteri per combinare righe con direzioni di testo diverse sulla stessa riga, i passaggi di testo visualizzati da destra a sinistra potrebbero sovrapporsi al testo normale esistente visualizzato da sinistra a destra.
Con questo metodo, un costrutto dannoso può essere aggiunto al codice, ma poi rendi invisibile il testo con questa costruzione durante la visualizzazione del codice, aggiungendo i caratteri mostrati da destra a sinistra nel commento successivo o all'interno del letterale, il che risulterà in un risultato di caratteri completamente diversi sovrapposti all'inserto dannoso. Tale codice sarà ancora semanticamente corretto, ma verrà interpretato e visualizzato in modo diverso.
Abbiamo scoperto modi per manipolare la codifica dei file di codice sorgente in modo che i visualizzatori e i compilatori umani vedano una logica diversa. Un metodo particolarmente dannoso utilizza i caratteri di sovrascrittura della direzionalità Unicode per visualizzare il codice come anagramma della sua vera logica. Abbiamo verificato che questo attacco funziona contro C, C++, C#, JavaScript, Java, Rust, Go e Python e sospettiamo che funzionerà contro la maggior parte degli altri linguaggi moderni.
Durante la revisione del codice, lo sviluppatore dovrà affrontare l'ordine visivo dei personaggi e vedrà un commento sospetto in un editor testo, interfaccia web o IDE, ma il compilatore e l'interprete utilizzeranno l'ordine logico dei caratteri e gestiranno il codice dannoso così com'è, indipendentemente dal testo bidirezionale nel commento. Sono interessati 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 "return" nascosta, che porta alla terminazione prematura dell'esecuzione della funzione; la conclusione nel commento di espressioni che normalmente sono considerate costrutti validi (ad esempio per disabilitare controlli importanti); assegnazione di altri valori di stringa che portano a errori di convalida della stringa.
Inoltre, è stata proposta un'altra opzione di attacco (CVE-2021-42694), che prevede l'uso di omoglifi, simboli che appaiono simili nell'aspetto, ma differiscono nel significato e hanno codici Unicode diversi. Questi caratteri 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 è possibile capire immediatamente quale di queste due funzioni viene chiamata in un determinato luogo.
Come misura di protezione, si consiglia di implementare in compilatori, interpreti e strumenti di assemblaggio che supportano i caratteri Unicode, mostrando un errore o un avviso se sono presenti caratteri di controllo non accoppiati nei commenti, nelle stringhe letterali o negli identificatori che modificano la direzione dell'output. Questi caratteri devono anche essere esplicitamente vietati nelle specifiche del linguaggio di programmazione e devono essere presi in considerazione negli editor di codice e nelle interfacce per lavorare con i repository.
a parte quello le vulnerabilità hanno già iniziato a essere risolte preparato per GCC, LLVM / Clang, Rust, Go, Python e binutils. Anche GitHub, Bitbucket e Jira stanno già preparando una soluzione insieme a GitLab.
Infine Se sei interessato a saperne di più, puoi consultare i dettagli nel seguente link.