Жил-был в норе под землей… разработчик группы разработки защитных решений безопасной платформы. Привет! Я Максим Жуков, занимаюсь безопасностью различных аспектов KasperskyOS. Расскажу про один из них, ELF-парсер.

Эта история не про то, как мы в «Лаборатории Касперского» сделали парсер с нуля. А про то, как я отправился в долгое исследовательское путешествие в поисках способа сделать наш существующий парсер безопаснее, что узнал о разных инструментах в пути и какую неожиданную помощь получил от Темного Владыки Мелькора.

Интересно будет тем, кто работает с бинарными данными, занимается безопасностью или просто хочет сделать свой код надежнее. Особое приглашение под кат — фанатам Rust, ему уделю немало внимания. Поехали!

Контекст задачи

Прежде чем перейти непосредственно к заявленной теме, считаю нужным рассказать немного про KasperskyOS и немного про формат ELF.

Вопрос доверия

Итак, есть KasperskyOS, есть ELF-файлы, которые надо безопасно парсить. На момент начала этой истории в нашей оси уже существовал ELF-парсер, написанный на C. И расположенный (внезапно) на user space, то есть отделенный от (микро)ядра. Он за время разработки и доработки прошел огонь, воду и:

• фаззинг через libFuzzer;

• статический анализ с PVS-Studio и Svace;

• динамический анализ с помощью Clang-стека и санитайзеров: AddressSanitizer, UndefinedBehaviorSanitizer;

• пентесты.

Уже взрослый, сложившийся инструмент. Но даже к такому решению всегда надо повышать уровень доверия: чем он выше, тем мы будем спокойнее спать по ночам.

Что нужно от безопасного парсера

Приступая к этой задаче, я хотел найти максимально безопасный парсер, который убережет от большинства уязвимостей, не сломается при парсинге любого ELF-файла, сможет обосновать доверие к кодовой базе и будет при этом открытым, без регистраций и СМС.

Риски при парсинге бинарных данных

Когда я говорю об уязвимостях, речь идет в основном о трех типах рисков. Есть и другие, но эти всплывают сразу, как только погружаешься в тему.

Во-первых, buffer overflow: парсим файл, доверяем данным в нем, переходим по смещению, оказываемся вообще в другом разделе памяти. Вот и готовый эксплойт.

Во-вторых, сломанные инварианты в структуре данных, которые нужно отдельно валидировать. Например, в ELF есть такой контракт — два сегмента данных не должны пересекаться и указывать на одну и ту же страницу памяти. Подобные вещи необходимо активно проверять / валидировать, иначе при пересечении памяти у нас будут одни и те же атрибуты памяти на данных и на коде, а это может привести к тому, что код можно будет изменить.

В-третьих, стандартные ошибки при парсинге: например, деление на ноль, переполнение при арифметических операциях и прочее. Тут без комментариев, думаю, понятно, почему это плохо и подобные вещи надо отлавливать.

Это реальные риски?

Вот лишь несколько CVE’шек, не связанных напрямую с ядром.

• CVE-2012-1429: пропуск файлов во время антивирусного сканирования.

• CVE-2018-6924: DoS-атака на ядро, результат — краш или доступ к памяти.

• CVE-2013-2196: доступ к правам local administrator.

• CVE-2023-1157: DoS-атака.

Играем в загадки

Перед тем как двинемся дальше, максимально наглядно покажу, почему внешним данным не стоит доверять, какие существуют риски. Посмотрите на этот код:

void *parse_data(const void *src, size_t size, size_t offset) {
        if (size + offset > MAX_SIZE || size < sizeof(Section))
                return NULL;
        void *buf = malloc(size + offset);
        if (!buf)
                return NULL;

        memcpy((char *)buf + offset, src, sizeof(Section));
        return buf;
}

Какие проблемы вы в нем видите?

void *parse_data(const void *src, size_t size, size_t offset) {
        if (size + offset > MAX_SIZE || size < sizeof(Section))      // при сложении может произойти переполнение
                return NULL;
        void *buf = malloc(size + offset); // выделяется малый размер памяти
        if (!buf)
                return NULL;

        memcpy((char *)buf + offset, src, sizeof(Section)); // записываем куда хотим
        return buf;
}

Больше примеров Эру Илуватару примеров: конкретно с unsigned overflow связана также CWE-502. Это базовая уязвимость: десериализация недоверенных данных.

Всегда есть вероятность, что придет плохой чел, поменяет байт в коде и попытается все сломать. Поэтому кодить нужно изначально с расчетом на это, все данные активно проверять.

Почитать подробнее можно здесь: правила секьюрного кодинга, тут поясняется, как не допускать unsigned overflow.

А вот целый топ уязвимостей за 2023 год, преобладают как раз связанные с небезопасной памятью:

Как защититься от угроз: правило двух

Простой свод правил, созданный Google. Есть три основных критерия:

• Парсинг может проходить в unsafe-языке, например C или C++.

• Код может работать с недоверенными данными.

• Процесс парсинга может происходить без сандбокса.

Соответствовать всем трем критериям — это то же самое, что надеть Кольцо Всевластия посреди Мордора и беззаботно дожидаться назгулов. Отсюда и правило двух — не более.

Где взять безопасного переводчика с эльфийского

У меня образовался целый ряд вариантов, как сделать наш ELF-парсер максимально безопасным.

• Заменить нашу разработку на open-source-вариант безопасного парсера.

• Переписать весь код парсера на Rust.

• Использовать генератор парсеров.

• Применить формальные методы, чтобы доказывать безопасность.

• Вооружиться методом model checking и дополнительно тестировать код.

Что мне было нужно от open-source-библиотек

Первым делом я погрузился в опенсорс. К идеалу были серьезные требования. Искал парсер с большой аудиторией: чем она больше и чем активнее проект, тем меньше багов и безопаснее код. При этом лицензия у него должна была быть не GPL, потому что у нас в KasperskyOS проприетарный код, и точно не нужны лишние проблемы с юридической стороны. Обязательны обширные тесты и покрытие: код должен доказывать, что работает и не содержит багов.

В плюс возможным кандидатам шло прохождение security-аудитов, прогоны через статический и динамический анализ.

На каждый идеал найдется свое но

Лень — двигатель прогресса: я загуглил «safe ELF-parsers» и начал изучать результаты.

rust-elf

Библиотека для парсинга ELF-файлов для Rust. Это меня сразу привлекло, хотелось поиграться с Rust в своем коде. Увы, смутило маленькое тестовое покрытие и то, что проект не развивается.

Выходило, что я притащу в KasperskyOS внешнюю зависимость, которую придется анализировать и развивать. А это мало отличается от переписывания существующего парсера с нуля.

libelfmaster

Безопасная библиотека для ELF-парсинга/загрузки, подходит для реконструкции вредоносов в форензике, содержит обширный инструментарий для реверс-инжиниринга. Написан на C, лицензия — BSD, однако последний факт удалось выяснить только из комментов.

Проблема в том, что этот проект тоже не развивается, тесты в нем только на регрессии, а хуже всего — в нем есть баги с security-уязвимостями, которые известны, но никто их не фиксит. Вот, вот и вот примеры.

elfutils

Коллекция утилит и библиотек для чтения, создания и модификации ELF-бинарников, также находит DWARF-данные дебагов, символы, поточные состояния, трассировку стека для процессов и файлов ядра и управляет ими.

Во всем замечательный проект: написан на C, популярен, развивается. Но под лицензией GPL, так что пришлось искать дальше.

LIEF

Библиотека для инструментации исполняемых форматов (C++, Python, Rust). Фреймворк написан на C++, в нашем случае нужно было бы делать биддинги для C-кода. Плюс, из-за того, что решение работает и с другими форматами, в нем было много лишнего для нас. А ранняя версия 0.15 обещала много ломающих изменений в кодовой базе, что явно не пойдет на пользу дальнейшему сопровождению парсера.

Итоги поисков

Дальше я искать не стал, экстраполировал проблему с rust-elf на все open-source-решения. Любая зависимость — потенциальная цель для атаки на цепочку поставок. Через малоиспользуемый компонент можно поменять код и встроить эксплойт в большой проект. Зависимости нужно будет контролировать, это дополнительные задачи и время.

Кроме того, многие проекты были еще в формате Proof of Concept, а каждое масштабное изменение — новая порция работы для нас.

Знакомство с Дарующим Безопасность Фаззером Всего

Зато в процессе поисков я познакомился с совершенно замечательным решением. Встречайте, Melkor ELF Fuzzer, или просто Мелькор.

В соответствии с заветами Толкина Мелькор извращает ELF-файлы. Делает он это с помощью случайных мутаций, того самого фазза. Получающиеся в результате искаженные файлы создатель Мелькора любовно называет орками.

В Мелькоре можно задать, какой тип данных будем фаззить, сколько орков нужно получить из исходного эльфа, с какой вероятностью применять каждое правило фаззинга.

Кроме того, в отличие от generic фаззеров, которые меняют случайные байты, Melkor понимает структуру ELF, а следовательно, делает более осознанные правки. Это позволяет исключить длительные попытки фаззера пройти все валидации.

Стандартному фаззеру нужно долго набирать корпус, чтобы проверки дошли глубже. Мелькор сразу тестит парсер на сложную логику: модифицирует готового эльфа, чтобы тот падал где-нибудь глубоко.

По ссылке — исследование многих заметных open-source-парсеров Мелькором от создателя решения и подборка интересных багов, которые с ним удалось найти.

Ну а я продолжил поиски оптимального решения.

Зачем переписывать код на Rust

Потому что Rust обеспечивает безопасность памяти, Memory Safety, которая складывается из ряда безопасностей поменьше.

• Пространственная безопасность (spatial safety): код не должен выходить за границы разрешенной ему памяти, самый банальный вариант такой памяти — буфер. В рантайме Rust при выходе за границы массива просто упадет.

• Временная безопасность (temporal safety): объект после освобождения не может быть исполнен. Borrow Checker трекает время исполнения объектов, если ссылки на объект переживают сам объект, происходит ошибка компиляции.

• Безопасность типов (type safety): код защищен от invasive cast. Rust запрещает неявное приведение типов.

• Безопасность до инициализации (define initialization safety): запрет на доступ к неинициализированным данным. Rust запрещает доступ к данным, которые не были явно проинициализированы, их даже указать нельзя, нужно сперва инициализировать.

• Поточная безопасность (thread safety): исключен доступ к одним и тем же данным одновременно из нескольких сегментов файла. С помощью системы типов и Borrow Checker’а Rust это гарантирует.

Погружение в каждый тип безопасности подробнее — в этом исследовании от Apple.

Итак, Rust — это идеал? Нууу…

Почему я не стал переписывать код на Rust

Мигрировать на новый стек дорого, долго и многозадачно. Так как сам компонент будет представлять собой библиотеку, которая внедряется в C-код, то внедрение становится заметно труднее.

Помимо того, что необходимо это как-то собрать, придется сделать биндинги C->Rust / Rust->C, после чего наладить запуск тестов в таком гибридном проекте с корректным покрытием. А также не забыть про харденинги, которые переходят через FFI-границу.

На этом слоеном торте из задач не одна и не две, а сразу три вишенки.

Биндинги с высокой вероятностью так или иначе отвалятся, и мы получим UB (Undefined Behavior). Проблема в том, что при генерации вызовов через FFI у нас нет четких гарантий, что интерфейс будет именно такой. Если у нас где-то есть объявление, что void foo(void ), а после foo будет void foo(void , char *), то вот тут и возникнет UB. А можно еще неправильно что-либо написать и сломать алиасинг.

Rust исключает только проблемы с memory safety, проблемы с logic safety останутся в программе. Ту же проблему с пересечением сегментов памяти Rust автоматом не проверит. Следовательно, ручная проверка инвариантов ELF останется на программисте.

Новый код — плацдарм для багов: в коде возрастом 5 лет и более в 3,4 раза меньше ошибок, чем в новом.

То есть — долго и дорого все переписывать, потом еще дольше править свежий код, который к тому же не закроет одно из трех ключевых направлений рисков. К сожалению, идею поиграться с Rust пришлось оставить.

Будущее за генераторами парсеров?

В поисках решения я наткнулся на статью от Microsoft. У них были многочисленные уязвимости в сетевом стеке ядра. В какой-то момент это их так достало, что они сделали EverParse3D.

Эта штучка с помощью C-подобных структур и инвариантов генерирует парсер. Пример структуры вот такой:

typedef struct _OrderedPair {
    UINT32 fst;
    UINT32 snd { fst <= snd };
} OrderedPair;

В статье обещали столь желанную memory safety, а еще arithmetic safety и полную функциональную корректность, никаких UB!

Однако бежать за трендом мне не захотелось, и вот почему. Для этого нужен был новый стек на F*. Дебажить сгенерированный код больно. Вносить правки — безумные затраты по времени, особенно с учетом функциональной корректности, для которой некоторые модели нужно было бы править отдельно. Не говоря уж о возможных закладках и уязвимостях. Проблема с инвариантами ELF при этом никуда не денется: сгенерированный парсер пропустит уязвимость, если мы в одном из инвариантов допустим ошибку.

Хотя я от идеи отказался, тему копнул чуть глубже и нашел исследование: автор сравнил генераторы парсеров и выяснил, что далеко не все из них генерируют корректный код без ошибок.

Формальные методы

Может, обвесить код нотацией и с помощью нее доказать, что все достаточно безопасно? Для этого есть фреймворк Frama-C. Он позволяет расставить инварианты в уже существующем коде. Тем самым мы добиваемся гарантий, поставляемых Rust и генераторами, при этом не переписывая весь код. В нотации можно указать эти самые инварианты от ожиданий наших функций. Выглядеть это может вот так:

/*@ requires n >= 0 && n < 100;
*/
int f(int n)
{
   int tmp = 100 − n;
   //@ assert tmp > 0;
   //@ assert tmp < 100;
   return tmp;
}

Но и тут минусы перевешивают плюсы. Формальные методы — сложный подход, это был бы новый для нашей команды и команды ядра инструмент. В «Лаборатории Касперского» есть отдельная команда формальных методов, однако человеку, не практикующему формальщину, вкатиться в этот подход непросто.

При этом у него есть заметные ограничения: Frama-C не работает с union’ами и динамической памятью. Для более сложных нотаций вообще требуется связка с Isabelle/HOL, а это еще один сложный инструмент.

Не говоря уж о том, что в нотации можно банально ошибиться, недоглядеть. Вот печальный кейс, авторы которого делали парсер для x.509-сертификатов. Как это всегда бывает, только в конце работы обнаружили баг в коде, из-за которого return value перезатирался. Всего объема нотаций не хватило, чтобы это своевременно выявить.

Model Checking

Последний из методов я исследовал с фокусом на опыт применения CBMC. С его помощью сотрудники Amazon валидировали свой код. CBMC работает с C17 и другими новейшими стандартами. С ним не нужно вводить лишние нотации: свойства программы проверяются с помощью unit-тестов. Проверяются memory safety, UB, user specified assert.

Вот примерчик unit-теста:

Здесь видна подготовка данных, задание первоначальных условий, вызов интересующих функций, проверка инвариантов в конце. Авторы теста пытаются с помощью символьного исполнения задать рандомный вход, проверить, что нет ошибок, что ассерты недостижимы и так далее.

Есть ли подводные камни? И снова:

Оперативки он ест немало и работает долго. Но это были достаточно незначительные минусы по сравнению с другими подходами.

Что я сделал по итогам поисков

Оставил уже имеющийся ELF-парсер на C без радикальных изменений, но дополнил его проверки новыми этапами. Теперь их шесть:

• фаззинг через libFuzzer;

• статический анализ с PVS-Studio и Svace;

• динамический анализ с Clang-стеком и санитайзерами;

• пентесты;

• продвинутый фаззинг с Melkor;

• unit-тесты с CBMC.

Melkor использую для дополнительного тестирования и сравнения, а с помощью CBMC залезаю в потроха, нахожу неочевидные моменты, когда в функции что-то не до конца проверено.

Хотя в итоге мы сосредоточились на харденинге существующего решения и не стали добавлять кардинально новые инструменты, их изучение все равно было полезным и дало новый опыт. При этом фокус на доработке, а не на переделывании с нуля, сэкономил ценное время.

Что делать вам

Значат ли итоги моих поисков, что всем компаниям и разработчикам надо строго дорабатывать старый парсер, а шаг вправо, шаг влево равен ереси? Нет, конечно. Я дал обзорный взгляд на целый ряд подходов к безопасности ELF-парсеров, у каждого свои плюсы. Теперь сформулирую ряд советов тем, кто решает подобную задачу у себя.

• Погружайтесь в инструменты, уделяйте время исследованиям, копайте глубже. Я именно благодаря им встретился с Мелькором, который теперь стал важной частью нашей работы с ELF-парсером.

• Изучайте альтернативные пути и варианты. Самая короткая дорога может оказаться самой удобной, но это далеко не гарантия.

• Подходите к коду планомерно и внимательно: для этого рекомендую почитать ГОСТ по разработке безопасного ПО. Шатаут моему коллеге Диме Шмойлову, принимавшему участие в создании стандарта.

Если собираетесь работать с внешними зависимостями:

• Всегда помните об атаке на цепочку поставок. Не тяните код напрямую с Гитхаба, проверяйте, что подключаете.

• Дополнительно тестируйте зависимости: статический и динамический анализ, фаззинг в помощь.

Если хотите применить Rust:

• Используйте его в новых проектах, а не переписывайте старые, чтобы было поменьше багов.

• Помните, что с ним нет гарантий функциональной корректности, ошибки логики он не закроет.

Если приглянулись формальные и полуформальные методы:

• Решайтесь, исходя из экспертизы команды и сложности сопровождения. Насколько вы реально хотите это все тянуть?

• Помните, что заформалить код можно, но менять его будет нельзя, иначе рассинхрон с моделью и болезненный обратный синхрон.

Наконец, мой главный совет: не будьте, как Исильдур.

Нельзя полагаться на инструмент. Нет резона искать в топе Гугла, что сейчас самое трендовое, а потом без задней мысли бежать и внедрять. Ни одно решение, даже самое хайповое, не гарантирует 100%-ное закрытие потребностей. Нужен прежде всего правильный процесс, учитывающий требования и риски.

Ну а я пойду в очередной раз почитаю «Сильмариллион». Безопасность ELF-парсера выросла, а с ней в очередной раз возросло и мое доверие к нему. Так что пока можно спать спокойно.

А вы пока можете больше узнать о KasperskyOS, если мой рассказ вас заинтриговал.