Атака 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» { // Проверка дали е администратор

Допълнително е предложен още един вариант на атака (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