Naukowcy z Uniwersytetu w Cambridge opublikowali technikę cichego umieszczania złośliwego kodu w recenzowanym kodzie źródłowym. Przygotowana metoda ataku (CVE-2021-42574) prezentowana jest pod nazwą Trojan Source i opiera się na tworzeniu tekstu, który wygląda inaczej dla kompilatora/interpretera i osoby przeglądającej kod. Przykłady metody zademonstrowano dla różnych kompilatorów i interpreterów dostarczonych dla języków C, C++ (gcc i clang), C#, JavaScript (Node.js), Java (OpenJDK 16), Rust, Go i Python.
Metoda opiera się na użyciu specjalnych znaków Unicode w komentarzach do kodu, które zmieniają kolejność wyświetlania tekstu dwukierunkowego. Za pomocą takich znaków sterujących niektóre fragmenty tekstu można wyświetlać od lewej do prawej, a inne od prawej do lewej. W codziennej praktyce takie znaki kontrolne można wykorzystać np. do wstawienia do pliku linii kodu w języku hebrajskim lub arabskim. Jeśli jednak połączysz w jednym wierszu linie o różnych kierunkach tekstu, używając określonych znaków, fragmenty tekstu wyświetlane od prawej do lewej mogą nakładać się na istniejący zwykły tekst wyświetlany od lewej do prawej.
Korzystając z tej metody, możesz dodać do kodu złośliwą konstrukcję, ale następnie sprawić, że tekst z tą konstrukcją będzie niewidoczny podczas przeglądania kodu, dodając następujący komentarz lub wewnątrz znaków dosłownych pokazanych od prawej do lewej, co doprowadzi do całkowitego na szkodliwe wstawki nakładane są różne znaki. Taki kod pozostanie semantycznie poprawny, ale będzie inaczej interpretowany i wyświetlany.
Przeglądając kod, programista skonfrontuje się z wizualną kolejnością znaków i zobaczy niepodejrzany komentarz w nowoczesnym edytorze tekstu, interfejsie internetowym lub IDE, ale kompilator i interpreter użyją logicznej kolejności znaków i przetworzyć złośliwe wstawienie w niezmienionej postaci, bez zwracania uwagi na dwukierunkowy tekst w komentarzach. Problem 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).
Istnieje kilka sposobów wykorzystania tej metody do realizacji szkodliwych działań: dodanie ukrytego wyrażenia „return”, które prowadzi do wcześniejszego zakończenia funkcji; komentowanie wyrażeń, które normalnie byłyby widoczne jako prawidłowe konstrukcje (na przykład w celu wyłączenia ważnych kontroli); przypisywanie innych wartości ciągów, które prowadzą do niepowodzeń sprawdzania poprawności ciągów.
Na przykład osoba atakująca może zaproponować zmianę zawierającą linię: if poziom_dostępu != "użytkownik{U+202E} {U+2066}// Sprawdź, czy admin{U+2069} {U+2066}" {
który będzie wyświetlany w interfejsie recenzji jako if access_level != „user” { // Sprawdź, czy admin
Dodatkowo zaproponowano inny wariant ataku (CVE-2021-42694), związany z wykorzystaniem homoglifów, czyli znaków o podobnym wyglądzie, ale różniących się znaczeniem i mających inny kod Unicode (np. znak „ɑ” przypomina „ a”, „ɡ” - „g”, „ɩ” - „l”). Podobnych znaków można używać w niektórych językach w nazwach funkcji i zmiennych, aby wprowadzić programistów w błąd. Na przykład można zdefiniować dwie funkcje o nierozróżnialnych nazwach, które wykonują różne działania. Bez szczegółowej analizy nie jest od razu jasne, która z tych dwóch funkcji jest wywoływana w konkretnym miejscu.
Ze względów bezpieczeństwa zaleca się, aby kompilatory, interpretery i narzędzia asemblera obsługujące znaki Unicode wyświetlały błąd lub ostrzeżenie, jeśli w komentarzach, literałach ciągów znaków lub identyfikatorach zmieniają kierunek wyjścia (U+202A, znajdują się niesparowane znaki kontrolne). U+202B, U+202C, U+202D, U+202E, U+2066, U+2067, U+2068, U+2069, U+061C, U+200E i U+200F). Takie znaki powinny być również wyraźnie zabronione w specyfikacjach języka programowania i powinny być przestrzegane w edytorach kodu i interfejsach repozytoriów.
Dodatek 1: Przygotowano łaty podatności dla GCC, LLVM/Clang, Rust, Go, Python i binutils. GitHub, Bitbucket i Jira również rozwiązały problem. Trwają prace nad poprawką GitLab. Aby zidentyfikować problematyczny kod, sugeruje się użycie polecenia: grep -r $'[\u061C\u200E\u200F\u202A\u202B\u202C\u202D\u202E\u2066\u2067\u2068\u2069]' /ścieżka/do/ źródło
Dodatek 2: Russ Cox, jeden z twórców systemu operacyjnego Plan 9 i języka programowania Go, skrytykował nadmierne skupienie się na opisanej metodzie ataku, która jest znana od dawna (Go, Rust, C++, Ruby) i nie jest traktowana poważnie . Według Coxa problem dotyczy głównie prawidłowego wyświetlania informacji w edytorach kodu i interfejsach internetowych, co można rozwiązać, korzystając podczas przeglądu z odpowiednich narzędzi i analizatorów kodu. Dlatego zamiast zwracać uwagę na ataki spekulacyjne, właściwsze byłoby skupienie się na ulepszaniu procesów przeglądu kodu i zależności.
Ras Cox uważa również, że kompilatory nie są właściwym miejscem do naprawienia problemu, ponieważ zakazując niebezpiecznych symboli na poziomie kompilatora, pozostaje ogromna warstwa narzędzi, w których użycie tych symboli pozostaje akceptowalne, takich jak systemy kompilacji, asemblery, menedżery pakietów oraz różne analizatory konfiguracji i dane. Jako przykład podano projekt Rust, który zakazał przetwarzania kodu LTR/RTL w kompilatorze, ale nie dodał poprawki do menedżera pakietów Cargo, która umożliwia podobny atak poprzez plik Cargo.toml. Podobnie pliki takie jak BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml i wymagania.txt mogą stać się źródłami ataków.
Źródło: opennet.ru