Badacze z Uniwersytetu w Cambridge opublikowali technikę niejawnego wstawiania złośliwego kodu do recenzowanych źródeł. Opracowana metoda ataku (CVE-2021-42574) jest znana jako Trojan Source i opiera się na tworzeniu tekstu wyświetlającego się inaczej dla kompilatora/interpretera i osoby przeglądającej kod. Przykłady zastosowania metody zostały zaprezentowane dla różnych kompilatorów i interpreterów dostarczanych dla języków C, C++ (gcc i clang), C#, JavaScript (Node.js), Java (OpenJDK 16), Rust, Go oraz Python.
Metoda ta opiera się na zastosowaniu w komentarzach do kodu specjalnych symboli Unicode, zmieniających kolejność wyświetlania dwukierunkowego tekstu. Dzięki takim znakom kontrolnym niektóre części tekstu mogą być wyświetlane od lewej do prawej, a inne od prawej do lewej. W codziennej praktyce takie znaki kontrolne mogą być stosowane na przykład do wstawiania do pliku z kodem linii w języku hebrajskim lub arabskim. Jednakże, jeśli połączyć linie o różnym kierunku tekstu w jednej linii, za pomocą tych znaków, fragmenty tekstu wyświetlane od prawej do lewej mogą zasłonić już istniejący standardowy tekst wyświetlany od lewej do prawej.
Wykorzystując tę metodę w kodzie można dodać złośliwą konstrukcję, ale następnie uczynić tekst z tą konstrukcją niewidocznym podczas przeglądania kodu, poprzez dodanie w następującym komentarzu lub wewnątrz literału znaków wyświetlających się od prawej do lewej, co doprowadzi do nałożenia zupełnie innych znaków na złośliwą wstawkę. Taki kod pozostanie semantycznie poprawny, ale będzie różnie interpretowany i wyświetlany.
W trakcie przeglądania kodu programista napotka wizualny porządek wyświetlania znaków i zobaczy w nowoczesnym edytorze tekstu, interfejsie webowym lub IDE niewzbudzający podejrzeń komentarz, ale kompilator i interpreter użyją logicznego porządku znaków i przetworzą złośliwą wstawkę tak, jak jest, nie zwracając uwagi na dwukierunkowy tekst w komentarzu. Problem ten dotyczy różnych popularnych edytorów kodu (VS Code, Emacs, Atom), a także interfejsów do przeglądania kodu w repozytoriach (GitHub, Gitlab, BitBucket i wszystkie produkty Atlassian).
Wyróżnia się kilka sposobów wykorzystania metody do realizacji złośliwych działań: dodawanie ukrytego wyrażenia „return”, prowadzącego do przedwczesnego zakończenia wykonania funkcji; umieszczanie w komentarzu wyrażeń, normalnie widocznych jako działające konstrukcje (na przykład w celu dezaktywacji ważnych sprawdzeń); przypisywanie innych wartości tekstowych, które prowadzą do awarii sprawdzenia tekstu.
Na przykład atakujący może zaproponować modyfikację, która zawiera linię: if access_level != „user{U+202E} {U+2066}// Sprawdź, czy admin{U+2069} {U+2066}” {
która będzie wyświetlana w interfejsie do przeglądania jako if access_level != „user” {// Sprawdź, czy admin
Dodatkowo zaproponowano jeszcze jeden wariant ataku (CVE-2021-42694), związany z wykorzystaniem homoglifów, symboli wyglądających podobnie, ale różniących się znaczeniem i mających różne kody unicode (na przykład symbol „ɑ” przypomina „a”, „ɡ” — „g”, „ɩ” — „l”). Takie symbole można używać w niektórych językach w nazwach funkcji i zmiennych, aby wprowadzić programistów w błąd. Na przykład mogą być zdefiniowane dwie funkcje o nieodróżnialnych nazwach, które wykonują różne działania. Bez szczegółowej analizy od razu nie da się zrozumieć, która z tych dwóch funkcji jest wywoływana w danym miejscu.
Jako środka ochrony zaleca się wdrożenie w kompilatorach, interpreterach i narzędziach do budowy, które obsługują symbole Unicode, wyświetlanie błędu lub ostrzeżenia w przypadku obecności w komentarzach, literałach tekstowych lub identyfikatorach nieparzystych znaków sterujących, które zmieniają kierunek wyświetlania (U+202A, U+202B, U+202C, U+202D, U+202E, U+2066, U+2067, U+2068, U+2069, U+061C, U+200E i U+200F). Takie symbole powinny być również wyraźnie zabronione w specyfikacjach języków programowania i powinny być brane pod uwagę w edytorach kodu i interfejsach do pracy z repozytoriami.
Uzupełnienie 1: Poprawki eliminujące lukę zostały przygotowane dla GCC, LLVM/Clang, Rust, Go, Python i binutils. Problem rozwiązano również w GitHub, Bitbucket i Jira. W trakcie przygotowania jest poprawka dla GitLab. Aby zidentyfikować problematyczny kod, zaproponowano użycie polecenia: grep -r $'[\u061C\u200E\u200F\u202A\u202B\u202C\u202D\u202E\u2066\u2067\u2068\u2069]' /path/to/source
Dodatek 2: Russ Cox, jeden z twórców systemu operacyjnego Plan 9 i języka programowania Go, skrytykował nadmierną uwagę poświęconą opisanej metodzie ataku, która od dawna jest znana (Go, Rust, C++, Ruby) i nie była traktowana poważnie. Według Coxa problem w głównej mierze dotyczy poprawności wyświetlania informacji w edytorach kodu i interfejsach webowych, co można rozwiązać, stosując odpowiednie narzędzia i analizatory kodu podczas przeglądów. Dlatego zamiast zwracać uwagę na teoretyczne ataki, lepiej byłoby skupić się na poprawie procesów przeglądania kodu i zależności.
Russ Cox również uważa, że kompilatory nie są odpowiednim miejscem do rozwiązywania problemu, ponieważ zakazując niebezpiecznych symboli na poziomie kompilatora, pozostaje ogromna gama narzędzi, w których użycie tych symboli jest nadal dozwolone, takich jak systemy budowy, assemblery, menedżery pakietów oraz różne parsery konfiguracji i danych. Dla przykładu można przytoczyć projekt Rust, który zakazał przetwarzania kodu LTR/RTL w kompilatorze, ale nie dodał poprawki do menedżera pakietów Cargo, co pozwala na przeprowadzenie podobnego ataku przez plik Cargo.toml. Podobnie źródłami ataków mogą być takie pliki jak BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml i requirements.txt.
Źródło: opennet.ru
