{"id":26051,"date":"2021-11-24T13:17:31","date_gmt":"2021-11-24T11:17:31","guid":{"rendered":"https:\/\/www.kaspersky.it\/blog\/?p=26051"},"modified":"2021-11-24T13:22:51","modified_gmt":"2021-11-24T11:22:51","slug":"trojan-source","status":"publish","type":"post","link":"https:\/\/www.kaspersky.it\/blog\/trojan-source\/26051\/","title":{"rendered":"Impianti invisibili nel codice sorgente"},"content":{"rendered":"

Gli esperti dell\u2019Universit\u00e0 di Cambridge hanno descritto<\/a> una vulnerabilit\u00e0 che dicono colpisca la maggior parte dei compilatori moderni. Un nuovo metodo di attacco utilizza una caratteristica legittima dei tool di sviluppo per cui il codice sorgente mostra una cosa ma compila qualcosa di completamente diverso. Succede Il tutto avviene attraverso la i caratteri di controllo Unicode.<\/p>\n

\"\"

Caratteri di formattazione della modalit\u00e0 Unicode rilevanti per gli attacchi di riordino. Fonte<\/a><\/p><\/div>\n

La maggior parte delle volte, i caratteri di controllo non appaiono sullo schermo con il resto del codice (anche se alcuni editor li visualizzano), ma modificano il testo in qualche modo. Questa tabella<\/a> contiene i codici per l\u2019algoritmo Unicode Bidirezionale (bidi), per esempio.<\/p>\n

Come probabilmente sapete, alcune lingue umane sono scritte da sinistra a destra (ad esempio, l\u2019inglese), altre da destra a sinistra (ad esempio, l\u2019arabo). Quando il codice contiene solo una lingua, non c\u2019\u00e8 problema, ma quando \u00e8 necessario, quando, per esempio, una riga contiene parole in inglese e in arabo, i codici bidi specificano la direzione del testo.<\/p>\n

\"\"

Esempio di codice Python vulnerabile usando i codici bidi. Fonte<\/a>.<\/p><\/div>\n

A destra \u00e8 la versione che i programmatori vedono quando controllano il codice sorgente; a sinistra si mostra come il codice verr\u00e0 eseguito. La maggior parte dei compilatori ignora i caratteri di controllo. Chiunque controlli il codice penser\u00e0 che la quinta linea sia un innocuo commento, anche se in realt\u00e0, una dichiarazione di ritorno anticipato nascosta all\u2019interno far\u00e0 s\u00ec che il programma salti l\u2019operazione che addebita i fondi del conto bancario. In questo esempio, in altre parole, il programma bancario simulato erogher\u00e0 denaro ma non ridurr\u00e0 il saldo del conto.<\/p>\n

Perch\u00e9 \u00e8 pericoloso?<\/h2>\n

A prima vista, la vulnerabilit\u00e0 sembra troppo semplice. Chi inserirebbe caratteri invisibili, sperando di ingannare i revisori del codice sorgente? Tuttavia, il problema \u00e8 stato ritenuto abbastanza serio da giustificare un identificatore di vulnerabilit\u00e0 (CVE-2021-42574<\/a>). Prima di pubblicare il documento, gli autori hanno avvisato gli sviluppatori dei compilatori pi\u00f9 comuni, dando loro il tempo di preparare le patch.<\/p>\n

Il rapporto delinea le capacit\u00e0 di attacco di base. Le due strategie di esecuzione sono nascondere un comando all\u2019interno dei commenti, e nascondere qualcosa in una linea che, per esempio, appare sullo schermo. \u00c8 possibile, in teoria, ottenere l\u2019effetto opposto: creare del codice che sembra un comando, ma in realt\u00e0 fa parte di un commento e non verr\u00e0 eseguito. Metodi ancora pi\u00f9 creativi per sfruttare questa debolezza sono destinati ad esistere.<\/p>\n

Per esempio, qualcuno potrebbe usare il trucco per portare avanti un sofisticato attacco alla supply chain in cui un appaltatore fornisce a una societ\u00e0 un codice che sembra corretto ma non funziona come previsto. Poi, dopo che il prodotto finale viene rilasciato, una parte esterna pu\u00f2 utilizzare la \u201cfunzionalit\u00e0 alternativa\u201d per attaccare i clienti.<\/p>\n

Quanto \u00e8 pericoloso, in realt\u00e0?<\/h2>\n

Poco dopo la pubblicazione del documento, il programmatore Russ Cox ha criticato l\u2019attacco Trojan Source. Non era convinto, per usare un eufemismo. I suoi argomenti sono i seguenti:<\/p>\n