Специалисты Кембриджского университета Николас Боучер (Nicholas Boucher) и Росс Андерсон (Ross Anderson) обнаружили новый класс уязвимостей, позволяющих злоумышленникам внедрять визуально обманчивое вредоносное ПО способом, который является семантически допустимым, но изменяет определенную исходным кодом логику, что делает код уязвимым к самым разным киберугрозам, в том числе связанными с цепочками поставок. Описанная специалистами техника под названием "Атака Trojan Source" базируется на использовании "неуловимых различий в стандартах кодирования символов наподобие Юникода для создания исходного кода, чьи токены логически закодированы не в том порядке, в каком они отображаются, что приводит к уязвимостям, которые рецензирующие код люди не могут увидеть". Уязвимости, получившие идентификаторы CVE-2021-42574 и CVE-2021-42694, затрагивают компиляторы всех популярных языков программирования, такие как C, C++, C#, JavaScript, Java, Rust, Go и Python. Проблема связана с двунаправленным алгоритмом Юникода (алгоритмом Bidi), обеспечивающим поддержку письма как слева направо (например, русский язык), так и справа налево (например, иврит). Алгоритм Bidia также поддерживает двунаправленное переопределение, позволяющее писать слова слева направо в предложении на языке с письмом справа налево и наоборот. Иначе говоря, алгоритм позволяет тексту, написанному слева направо, восприниматься как написанный справа налево. Предполагается, что выходные данные компилятора будут корректно реализовывать исходный код, однако несоответствия, возникающие при вставке символов переопределения Юникода Bidi в комментарии и строки, позволяют создавать синтаксически допустимый исходный код, в котором порядок отображения символов представляет логику, которая расходится с реальной логикой. "То есть, мы анаграммируем программу A в программу Б. Если изменения в логике достаточно неуловимые для того, чтобы обходить обнаружение в последующих тестированиях, злоумышленник может создать целевые уязвимости и не быть обнаруженным", - пояснили исследователи. Подобное состязательное программирование может оказать серьезное влияние на цепочку поставок, предупреждают исследователи, когда внедренные в ПО с открытым исходным кодом уязвимости передаются конечным продуктам, затрагивая всех пользователей программного обеспечения. Хуже того, "Атака Trojan Source" может стать более серьезной, если злоумышленник использует омоглифы для переопределения ранее существовавших функций в исходном пакете и вызова их из программы-жертвы. https://www.securitylab.ru/news/526144.php
Атака Trojan Source для внедрения изменений в код, незаметных для разработчика Исследователи из Кембриджского университета опубликовали новую технику незаметной подстановки вредоносного кода в рецензируемые исходные тексты. Подготовленный метод атаки (CVE-2021-42574) представлен под именем Trojan Source и базируется на формировании текста по разному выглядящего для компилятора/интерпретатора и человека, просматривающего код. Примеры применения метода продемонстрированы для различных компиляторов и интерпретаторов, поставляемых для языков C, C++ (gcc и clang), C#, JavaScript (Node.js), Java (OpenJDK 16), Rust, Go и Python. Метод основан на применении в комментариях к коду специальных Unicode-символов, меняющих порядок отображения двунаправленного текста. При помощи подобных управляющих символов одни части текста могут выводиться слева-направо, а другие справа-налево. В повседневной практике подобные управляющие символы могут применяться, например, для вставки в файл с кодом строк на иврите или арабском языке. Но если комбинировать строки с разным направлением текста в одной строке, при помощи указанных символов отрывки текста, отображаемые справа-налево могут перекрыть уже имеющийся обычный текст, отображаемый слева-направо. Используя данным метод в код можно добавить вредоносную конструкцию, но затем сделать текст с этой конструкцией незаметным при просмотре кода, через добавление в следом идущем комментарии или внутри литерала символов, показываемых справа-налево, что приведёт к наложению на вредоносную вставку совершенно других символов. Подобный код останется семантически корректным, но будет по разному интерпретироваться и отображаться. В процессе рецензирования кода разработчик столкнётся с визуальным порядком вывода символов и увидит в современном текстовом редакторе, web-интерфейсе или IDE не вызывающий подозрения комментарий, но компилятор и интерпретатор будет использовать логический порядок символов и обработает вредоносную вставку как есть, не обращая внимание на двунаправленный текст в комментарии. Проблеме подвержены различные популярные редакторы кода (VS Code, Emacs, Atom), а также интерфейсы для просмотра кода в репозиториях (GitHub, BitBucket). Выделяются несколько способов использования метода для реализации вредоносных действий: добавление скрытого выражения "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). Подобные символы также должны быть явно запрещены в спецификациях языков программирования и должны учитываться в редакторах кода и интерфейсах для работы с репозиториями. 01.11.2021 https://www.opennet.ru/opennews/art.shtml?num=56083