Атаката Trojan Source за внедряване на промени в кода, които остават незабелязани от разработчика

Изследователи от Кеймбриджкия университет публикуваха техника за незабележимо вмъкване на злонамерен код в рецензирани изходни текстове. Подготвеният метод на атака (CVE-2021-42574) е представен под името Trojan Source и се основава на формиране на текст, различаващ се по вид за компилатора/интерпретатора и за човека, преглеждащ кода. Примери на прилагане на метода са демонстрирани за различни компилатори и интерпретатори, предоставяни за езици C, C++ (gcc и clang), C#, JavaScript (Node.js), Java (OpenJDK 16), Rust, Go и Python.

Методът се основава на приложението в коментарите на кода на специални Unicode символи, променящи реда на визуализацията на движещия се текст. С подобни управляващи символи, една част от текста може да бъде показана отляво надясно, а друга – отдясно наляво. В ежедневната практика, подобни управляващи символи могат да се използват, например, за вмъкване в файл с код на редове на иврит или арабски. Но ако комбинирате редове с различна посока на текста в една линия, чрез посочените символи, части от текста, показвани отдясно наляво, могат да закрият вече съществуващия обикновен текст, показван отляво надясно.

Използвайки този метод, в кода може да бъде добавена злонамерена конструкция, но след това текстът с тази конструкция да остане незабележим при преглед на кода, чрез добавяне в последващ коментар или вътре в литерал на символи, показвани отдясно наляво, което ще доведе до наложение на злонамерен код с напълно различни символи. Такъв код ще остане семантично коректен, но ще бъде интерпретиран и визуализиран по различен начин.

По време на рецензия на кода, разработчикът ще се сблъска с визуалния ред на изхода на символите и ще види в съвременен текстови редактор, уеб интерфейс или IDE коментар, който не буди съмнения, но компилаторът и интерпретаторът ще използват логичният ред на символите и ще обработят злонамерената вмъкване така, както е, без да обръщат внимание на движещия се текст в коментара. Проблемът застрашава различни популярни редактори на код (VS Code, Emacs, Atom), както и интерфейсите за преглед на код в хранилища (GitHub, Gitlab, BitBucket и всички продукти на Atlassian).

Изолирани са множество начини за използване на метода за извършване на злонамерени действия: добавяне на скрито изразяване „return“, което довежда до преждевременно завършване на функцията; коментиране на изрази, които нормално биха били видими като валидни конструкции (например за деактивиране на важни проверки); присвояване на различни строкови стойности, които водят до провали в проверките на низовете.

Например, нападателят може да предложи изменение, включващо ред: if access_level != „user{U+202E} {U+2066} // Check if admin{U+2069} {U+2066}” {

което ще бъде показано в интерфейса за рецензиране като if access_level != „user” { // Check if admin

Допълнително е предложен още един вариант на атака (CVE-2021-42694), свързан с използването на омоглифи, символи, които изглеждат подобно, но имат различно значение и различни unicode кодове (например, символът „ɑ“ наподобява „a“, „ɡ“ — „g“, „ɩ“ — „l“). Подобни символи могат да бъдат използвани в някои езици в имената на функции и променливи, за да заблуждават разработчиците. Например, могат да бъдат определени две функции с неразличими имена, извършващи различни действия. Без детайлно разглеждане веднага не е ясно коя от двете функции се извиква на конкретното място.

Като мярка за защита се препоръчва реализация в компилаторите, интерпретаторите и инструментите за сборка, поддържащи Unicode символи, за генериране на грешка или предупреждение при наличие на нечетни управляващи символи, променящи посоката на изхода (U+202A, U+202B, U+202C, U+202D, U+202E, U+2066, U+2067, U+2068, U+2069, U+061C, U+200E и U+200F) в коментарите, строковите литерали или идентификаторите. Подобни символи също трябва да бъдат изрично забранени в спецификациите на програмните езици и трябва да се вземат предвид в редакторите на код и интерфейсите за работа с хранилища.

Допълнение 1: Поправките за отстраняване на уязвимостта са подготвени за GCC, LLVM/Clang, Rust, Go, Python и binutils. Проблемът също е решен от GitHub, Bitbucket и Jira. В процес е подготовката на поправка за GitLab. За откритие на проблемния код е предложена команда: grep -r $'[\u061C\u200E\u200F\u202A\u202B\u202C\u202D\u202E\u2066\u2067\u2068\u2069]’ /path/to/source

Допълнение 2: Раз Кокс (Russ Cox), един от разработчиците на ОС Plan 9 и езика за програмиране Go, критикува прекомерното внимание към описания метод на атака, който отдавна е известен (Go, Rust, C++, Ruby) и не е бил вземан на сериозно. Според Кокс, проблемът основно се отнася до коректността на показването на информацията в редакторите на код и уеб интерфейсите, и се решава чрез прилагане на правилни инструменти и анализатори на код при рецензиране. Затова, вместо да се акцентира на умозрителни атаки, би било по-правилно да се фокусира вниманието върху подобряване на процесите на рецензиране на кода и зависимостите.

Раз Кокс също така смята, че компилаторите не са местото, където трябва да се решава проблемът, тъй като забраната на опасни символи на ниво компилатор оставя огромен пласт инструменти, в които ползването на тези символи остава допустимо, като например системи за изграждане, асемблери, пакетни мениджъри и различни парсери на конфигурации и данни. За пример е даден проектът Rust, който е забранил обработката на LTR/RTL код в компилатора, но не е добавил корекция в пакетния мениджър Cargo, което позволява извършване на аналогична атака чрез файла Cargo.toml. Аналогично, източниците на атаки могат да станат файлове като BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml и requirements.txt.

Източник: opennet.ru