Результаты тренировки моделей машинного обучения принято сохранять, и для этого существует множество форматов хранения. В предыдущей статье был представлен обзор статических сканеров артефактов ML-моделей, где ModelAudit выделялся как наиболее зрелое решение по количеству поддерживаемых форматов, числу проверок, устойчивости к обходу и качеству документации. Однако количество не всегда означает качество.

Для оценки возможностей сканеров в реальных условиях были проведены два ключевых эксперимента:

1. Сканирование моделей из Hugging Face, сериализованных в наиболее опасных форматах (например, .pkl, .pt, .ckpt).
2. Сканирование моделей, помеченных авторами как зловредные, с последующим сравнением результатов ModelAudit и встроенных в Hugging Face инструментов.

Несмотря на высокую чувствительность ModelAudit, многие сработки оказались ложноположительными. Например, модель Ultralytics/YOLO11 вызвала 728 предупреждений, из которых 35 — критических. При анализе выяснилось, что срабатывания связаны с использованием легитимных функций Python, таких как getattr и set, которые сканер классифицирует как подозрительные без глубокого анализа контекста.

Первый эксперимент — сканирование моделей в опасных форматах

Было отобрано 246 моделей, в которых найдено 271 критическое предупреждение. Однако лишь 34 модели имели хотя бы одну критическую сработку. Основные типы срабатываний:

• pytorch_binary_check — обнаружение сигнатуры PE-файла (Windows executable) в бинарных файлах. Все такие сработки оказались ложноположительными, так как касались моделей от известных компаний (Apple, OpenVINO).
• pytorch_zip_check — срабатывание на использование __builtin__.getattr, __builtin__.set и других базовых объектов. Также включает ложные сработки на атрибут input в TorchScript-моделях.
• pickle_check — обнаружение __builtin__.getattr и dill._dill._load_type. Последнее связано с легитимным использованием библиотеки dill в YOLOv8.

Вывод: высокое число сработок не означает зловредность. Многие проверки ModelAudit избыточно чувствительны и требуют доработки логики для снижения шума.

Второй эксперимент — сканирование меченых моделей

Цель — сравнить ModelAudit с встроенными в Hugging Face механизмами проверки. Были отобраны модели с ключевыми словами вроде "malicious", "ACE PoC", "deserialization PoC". После фильтрации через LLM и сканирования получена следующая картина:

• 154 модели были признаны опасными и ModelAudit, и Hugging Face.
• 49 — безопасными обеими системами.
• 6 — опасными по версии HF, но безопасными по ModelAudit (ложные отрицания, FN).
• 14 — опасными по ModelAudit, но безопасными по HF.

HuggingFace сигнализирует, но ModelAudit пропускает

Изначально ModelAudit (версия 0.2.24) пропускал 6 моделей, отмеченных HF как опасные. После обновления до 0.2.28 количество FN сократилось до 3, а в версии 0.2.31 все уязвимости были устранены. Причина — сложность обработки форматов вроде .ckpt, которые могут содержать Pickle-объекты внутри архивов, но не всегда распознаются как таковые.

Например, модель etwithin/diffusers-ckpt-ace-poc содержит Pickle-файл с эксплойтом, выполняющим произвольный код через posix.system. Сканер не применял соответствующие проверки, хотя они встроены. После ручного анализа с помощью Fickling угроза была подтверждена.

ModelAudit сигнализирует, но HuggingFace пропускает

26 моделей прошли проверки Hugging Face, но были помечены ModelAudit как опасные. Среди них:

• jossefharush/gpt2-rs — найдена сеть-активность и ссылка на Pastebin с бэкдором, который отправляет вывод команд на сервер злоумышленника. Сработка уровня INFO, но с высокой значимостью.
• treforbenbow/tensorrt-engine-rce-poc — в старых версиях ModelAudit срабатывал на строковые паттерны, связанные с RCE. В новых версиях логика изменилась, и сработки исчезли, хотя угроза осталась. Это позволило обойти проверку — уязвимость, исправленная после приватного отчёта.
• AgentRen/hdf5-h5hl-fl-deserialize-hbo-poc — подтверждённый PoC уязвимости heap-buffer-overflow в HDF5. True Positive.

Интересно, что исправление уязвимости в ModelAudit было выполнено не человеком, а ботом mldangelo-oai, что указывает на активное использование AI-агентов в разработке и поддержке инструмента.

Выводы

После учёта всех обновлений и исправлений:

• Все модели, отмеченные опасными в Hugging Face, также распознаются ModelAudit.
• 17 моделей признаны опасными только ModelAudit и не имеют предупреждений в HF.

Ключевые итоги:

• ModelAudit — мощный и проработанный инструмент, способный находить угрозы, пропущенные другими системами.
• Ложноположительные сработки — цена высокой чувствительности, но они лучше ложноотрицательных.
• Сравнение сканеров позволяет выявлять скрытые недостатки в логике проверок.
• Поддержка ModelAudit всё больше автоматизирована — инструменты для проверки моделей развиваются с помощью самих моделей.

Статья носит исключительно информационный характер и не является инструкцией или призывом к совершению противоправных действий. Цель — рассказать о существующих уязвимостях, которыми могут воспользоваться злоумышленники, предостеречь пользователей и дать рекомендации по защите личной информации в Интернете. Автор не несёт ответственности за использование информации.

• Введение
• Первый эксперимент - сканируем модели в наиболее опасных форматах храненияАнализ сработок самой уловистой моделиАнализ всех критических сработок из сканирования первого подмножества моделейВыводы по первому эксперименту
• Второй эксперимент - сканируем меченые моделиНюансыНаложение результатов сканированияHuggingFace сигнализирует об опасности, но ModelAudit пропускаетModelAudit сигнализирует об опасности, но HuggingFace пропускает
• Выводы

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

В предыдущей статье "Сканеры ML-моделей: разбор инструментов и некоторых методов обхода их проверок" был представлен обзор основных статических сканеров артефактов ML-моделей. В выводах сканер ModelAudit был выделен как наиболее зрелое решение среди проанализированных конкурентов по следующим критериям:

• количество поддерживаемых к сканированию форматов хранения моделей
• количество проверок под каждый формат моделей
• результаты моих попыток обхода сканеров
• наличие и качество документации

Но, как известно, количество не всегда отражает качество.

Для оценки возможностей сканера в более приближенных к реальности условиях я провел множество экспериментов и хочу поделиться двумя наиболее интересными:

1. Сканирование подмножества моделей из Hugging Face, сериализованных в виде наиболее опасных форматов хранения моделей
2. Сканирование таких моделей из Hugging Face, которые сами авторы пометили зловредными (в названии или описании) с последующим сравнением сработок ModelAudit с результатами проверок встроенных в HF инструментов

Немного спойлеров:

1. По результатам первого эксперимента разобраны наиболее фолсящие проверки ModelAudit (некоторые из которых сгенерировали в сумме 700+ сработок в популярной моделиUltralytics/YOLO11)
2. Второй эксперимент позволяет оценить разницу между результатами работы целого арсенала инструментов и всего лишь одного ModelAudit
3. По ходу рассмотрим, как ML-модели практически без участия человека обслуживают инструментарий, созданный для проверки тех же моделей

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

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

Меня зовут Вячеслав Мосин, я учусь вмагистратуре AI Talent Hubв ИТМО и прохожу практику в лабораторииITMO AI Security Lab. Эта статья написана в рамках работы лаборатории.

Первый эксперимент - сканируем модели в наиболее опасных форматах хранения

На Hugging Faceопубликованоуже более 2,7 миллиона моделей — просканировать их все на обычном компьютере не получится и за год. Поэтому нам нужно сузить выборку: отобрать те модели, которые с наибольшей вероятностью окажутся опасными.

Для этого можно отбирать к дальнейшим проверкам только те модели, в репозиториях которых есть артефакты наиболее опасных форматов. Но какие форматы отнести к таким?

Разработчики ModelAudit сами дают ответ на этот вопрос – вописании проектана PyPI они классифицировали совместимые форматы по уровням опасности:

Общая механика данного эксперимента стала следующей:

1. При помощи HF API и библиотекиhuggingface_hubформируем список идентификаторов репозиториев моделей на Hugging Face по следующим фильтрам:Среди артефактов в репозитории модели должен присутствовать хотя бы один с типом из списка:'.pkl', '.pickle', '.dill', '.pt', '.pth', '.ckpt', '.bin', '.joblib', '.npy', '.npz'Суммарный размер всех файлов в репозитории не должен превышать 1 ГБ (чтобы за меньшее время проверить большее число моделей)Количество скачиваний модели за последний месяц не более 10000 (популярные модели с меньшей вероятностью могут оказаться зловредными)Репозиторий должен быть открытым – не "gated" (на Hugging Face существуют репозитории, у которых "Model Card" доступна всем для просмотра, а для скачивания файлов нужно выполнить дополнительное действие, например, принять условия использования модели – для упрощения такие репозитории просто пропускаются)
2. В цикле скачиваем модели и сканируем при помощи ModelAudit
3. Сработки сохраняем в отдельный JSON
4. Анализируем собранные данные

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

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

Возможные уровни опасности (Severity) в результатах сканирования ModelAudit выглядят так (переводдокументации):

• CRITICAL: Критические проблемы безопасности, требующие немедленного устранения
• WARNING: Потенциальные проблемы, требующие проверки
• INFO: Информационные сообщения, не обязательно связанные с безопасностью
• DEBUG: Дополнительные сведения (отображаются только с помощью--verbose)

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

• unknown_check
• pytorch_zip_check
• pickle_check
• license_warning
• suspicious_url
• safetensors_check
• manifest_check
• pytorch_binary_check
• weight_distribution_check
• zip_check

Наконец, перейдём к результатам – начнём с 15 наиболее проблематичных моделей по сумме сработок всех типов:

Анализ сработок самой уловистой модели

Самая богатая на сработки модельUltralytics/YOLO11получила 728 предупреждений. Является ли это хорошим маркером зловредности модели? Вдобавок можно отметить её высокую популярность – неужели многие используют зловредную модель?

Чтобы не распыляться рассмотрим только критические предупреждения, всего их 35 штук. Из них 20 относятся к"type": "pickle_check"и 15 к"type": "pytorch_zip_check".

Анализ сработок с типомpickle_check:Все критические сработки данного типа имеют одинаковые значения атрибута "message":Suspicious reference __builtin__.getattr", между этими сработками отличаются лишь названия артефактов, в которых они были найдены, ниже представлено несколько примеров таких сработок:

getattr(obj, name)— стандартная Python-функция, которая получает атрибут объекта по имени, переданному в виде строки. То естьgetattr(obj, "method")эквивалентноobj.method. Эта функция может использоваться при создании зловредных файлов для обхода слишком наивных сканеров – при ее помощи можно импортировать любой объект по строке, которая, к примеру, до передачи вgetattrможет храниться отдельными кусками для усложнения анализа.

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

Анализ сработок с типомpytorch_zip_check:Сработки этого типа между собой тоже имеют много общего - они подсвечивают разные артефакты моделиUltralytics/YOLO11по наличию в них как минимум одного глобального имени из числа следующих:

Функциюgetattrмы уже разбирали, теперь поговорим проbuiltin.set– тип данных Python, реализующий коллекцию уникальных элементов (аналог математического множества). Как иgetattr, он живёт в пространстве имёнbuiltinи доступен без импорта. Это один из самых базовых и безобидных типов в языке.

Удивительно видеть сработку критического уровня, вызванную наличием стандартного типа данных, более того, безобидность использованияsetподтверждается в том числе и исходным кодом проверок типаpickle_check(modelaudit/scanners/pickle_scanner.py):

Но внутренний сканер типаpytorch_zip_checkне проверяет отдельные функции на легитимность – всё из пространства именbuiltinсчитается зловредным (modelaudit/scanners/pytorch_zip_scanner.py#L1977):

Из анализа сработок моделиUltralytics/YOLO11можно сделать следующие выводы:

• Высокое количество сработок (даже критических) не доказывает зловредность модели, а скорее служит сигналом для более детального ручного анализа – как самой модели, так и применяемых правил сканирования
• Существуют такие функции, которые часто применяются при сериализации легитимных моделей и одновременно являются полезными для составления зловредных файлов (такие функции как, например,getattr), для проверок таких функций необходима сложная логика, которая на данный момент в ModelAudit реализована не для всех кейсов

Анализ всех критических сработок из сканирования первого подмножества моделей

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

Первым делом оценим распределение критических алертов по типам сканеров:

Сработки типаpytorch_binary_checkОказалось, что все полученные сработки такого типа имеют одинаковое значение поляmessage: "Executable signature found: Windows executable (PE)". Ниже представлено несколько примеров таких сработок, найденных в моделиapple/coreml-depth-anything-v2-small:

Такие и аналогичные сработки генерирует сканер если в проверяемом файле удается найти одну из следующих сигнатур (modelaudit/detectors/suspicious_symbols.py#L565):

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

• В помеченных моделях нет критически опасных сработок других типов
• Среди отобранных все модели с такими сработками оказались опубликованными довольно известными компаниями (apple, OpenVINO, FluidInference)

Сработки типаpytorch_zip_checkНаходки данного типа можно разделить на две группы:

1. Cтриггерились на наличие в файлах моделей как минимум одного из следующих глобальных имен:__builtin__.set,__builtin__.getattr,__builtin__.dict- такие сработки мы уже разбирали ранее
2. Сработки в моделях сохраненных при помощи TorchScript, пример описания одной из таких сработок: "Found 9 JIT/Script code risks across file"

Большинство сработок второй группы имеют одинаковый источник проблемы - им выступает название атрибута равное "input", которое используется во многих PyTorch методах и не представляет собой одноименную функцию. Это видно напрямую по "code_snippet" из каждой аналогичной сработки:

Сработки типаpickle_checkКритических алертов такого типа в сумме 28 штук, из них 24 подсветили уже разобранную ранее проблему "Suspicious reference__builtin__.getattr5", оставшиеся 4 сработки сообщают об одной из следующих проблем:

1. Suspicious referencedill._dill._load_type
2. Found REDUCE opcode with non-allowlisted global:dill._dill._load_type. This may indicate CVE-2025-32434 exploitation (RCE via torch.load)
3. Extreme stack depth (30001) - stopping scan for safety

Все алерты, связанные сdill._dill._load_typeотносятся к одной модели с названиемDILHTWD/documentlayoutsegmentation_YOLOv8_ondoclaynet.

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

Пример сериализации с использованием Dill изпредыдущей статьи:

Возвращаясь кdill._dill._load_type- это вспомогательная функция десериализации внутри dill, которая восстанавливает Python-типы по их имени из внутренней таблицы_typemap.

Для моделей архитектуры YOLOv8 использование dill является стандартной практикой.

Выводы по первому эксперименту

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

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

Второй эксперимент - сканируем меченые модели

В предшествующем анализе удалось собрать аналитику по ошибкам типа "False Positive", но может возникнуть вопрос – раз ModelAudit так часто "фолзит" помечая легитимные модели зловредными, то как он поведет себя с действительно опасными моделями? И стоит ли вообще использовать ModelAudit, после всех тех проверок, которые и так прогоняются на Hugging Face?

Для получения ответов на эти вопросы был построен эксперимент со следующей последовательностью шагов:

1. Поиск таких моделей, у которых в репозитории встречаются определенные ключевые слова, сигнализирующие о зловредности модели с высокой вероятностью – для этого использовался полнотекстовый поиск по Hugging Face с применением нескольких запросов:"malicious","ACE" "PoC","deserialization" "PoC". В итоге получен список -parsed_raw_models_list.json
2. Фильтрация списка через LLM: в контекст модели передаём название репозитория, его описание и результаты HF-проверок – на выходе получаем подборкуfiltered_models_list.jsonс наибольшей вероятностью зловредных моделей
3. Сканирование итогового списка моделей через ModelAudit, с итогами сканирований можно ознакомиться в файлеscanned_data.json
4. Сопоставление итогов проведенного сканирования с результатами встроенных в HF проверок

Для первого ознакомления с результатами очередного сканирования снова построим гистограмму распределения сработок всех уровней критичности по 15 самым уловистым моделям. Сразу можно заметить несколько отличий от аналогичного распределения из первого эксперимента: процент критических сработок сильно выше, почти нет моделей с заоблачными количествами алертов (в предыдущем эксперименте было 9 моделей у которых больше 60 сработок, в текущем, как видно ниже, всего одна такая модель).

На предыдущей гистограмме высота столбцов в конце графика почти не убывала, поэтому ниже построена аналогичная гистограмма, но уже для 30 моделей:

Графики получились залипательные, но эксперимент задумывался с другой целью - сравнить сканирование при помощи одного инструмента с арсеналом встроенных в Hugging Face проверок.

Перед тем как перейти непосредственно к такому сканированию необходимо уточнить несколько нюансов:

Проблемы с проверками моделей на HF

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

Разные уровни опасности в сработках из Hugging Face и генерируемых через ModelAuditСработки, получаемые из HF API, нигде не задокументированы, но среди полученных мной данных были только вот такие варианты уровней опасности:

При этом результаты сканирований при помощи ModelAudit могут получать следующие уровни критичности:

Интерпретация уровней опасности ModelAudit описана вдокументации.

Наложение результатов сканирования

Если быть точным - сравнивать будем результаты проверок не совсем моделей, а их репозиториев, внутри которых может быть разное число моделей.

В текущем сравнении опасными будем считать те репозитории для которых есть хотя бы одна сработка с одним из следующих уровней:

• Для сработок из HF:'suspicious', 'unsafe'
• Для сработок от ModelAudit:'IssueSeverity.CRITICAL', 'IssueSeverity.WARNING'

То есть алгоритм сравнения получается примерно следующим:

1. Открываем репозиторий очередной модели и получаем артефакты проверок из двух источников: HF API и ModelAudit
2. Проходимся по срабатываниям ModelAudit – если есть хотя бы один алерт с уровнем'IssueSeverity.CRITICAL'или'IssueSeverity.WARNING', то модель считается опасной по оценке ModelAudit
3. Аналогично для HF - если среди срабатываний есть хотя бы один статус'suspicious'или'unsafe', то модель отмечаем опасной по оценке Hugging Face
4. По результатам обхода всех моделей строим Confusion Matrix

В итоге и была построена следующая матрица:

Пояснение к матрице:

• На главной диагонали расположены количества моделей, для которых и HF, и ModelAudit выдали одинаковые результаты проверок, среди них 154 модели были отмечены опасными обоими и, соответственно, 49 оценены как безопасные
• На побочной диагонали распложены количества моделей в которых предсказания разошлись

На матрице видно 14 репозиториев моделей которых ModelAudit счел опасными, однако встроенные в HF проверки для них не нашли ничего подозрительного.

Это число можно попробовать увеличить, пометив опасными в том числе и те репозитории, которые имеют хотя бы один алерт от ModelAudit одного из уровней:'IssueSeverity.CRITICAL', 'IssueSeverity.WARNING', 'IssueSeverity.INFO'(к предшествующему списку добавился уровень'IssueSeverity.INFO'). Но бывают ли действительно опасные сработки с уровнем INFO? Ещё как!

Ниже представлена одна из сработок, полученная при проверке моделиjossefharush/gpt2-rs:

Как видно, сканер нашел признаки объектов, связанных с сетевой активностью в файлеjossefharush_gpt2rs/pytorch_model.bin:pytorch_model/data.pkl.

Одной из найденных ссылок являетсяhttps://pastebin.com/raw/sVvZph7V– откроем ее:

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

Проведем новое сравнение, в котором опасными сработками ModelAudit будут считаться еще и те, которым присвоен уровеньIssueSeverity.INFO:

HuggingFace сигнализирует об опасности, но ModelAudit пропускает

Суммарное число опасных алертов увеличилось, теперь проанализируем расхождения и сфокусируемся на тех случаях, когда HF отмечал модели опасными, а ModelAudit безопасными, это произошло с шестью моделями:

Изначально я использовал ModelAudit версии 0.2.24, все вышеуказанные результаты были получены именно при помощи этой версии. Получив шесть потенциальных FN я обновил сканер до актуальной на тот момент версии – 0.2.28 и из шести FN осталось только три. Далее я убедился, что эти модели действительно зловредные (способы будут описаны ниже) и уже собирался зарепортить уязвимости обхода защиты ModelAudit, так как согласно егополитике безопасностиошибки приводящие к FN в поддерживаемых к сканированию форматах хранения считаются уязвимостями.

Подготовившись к этому я снова обновился на актуальную версию (0.2.31) и уже в этой версии все ошибки были устранены – такая вот история.

Использованные техники триажа находок ModelAuditСканер ModelAudit является по-настоящему глубоко проработанным решением - в него встроеномножество проверокпод различные форматы хранения. Но способов хранения моделей существует еще больше чем проверок, притом одно и то же расширение файла в разных фреймворках может обозначать различные по структуре и содержанию артефакты. Один из таких примеров – расширение.ckpt(сокращение от «checkpoint»), применяемое в ряде фреймворков:

• TensorFlow -https://www.tensorflow.org/tutorials/keras/save_and_load?hl=ru
• JAX Checkpoint -https://www.promptfoo.dev/docs/model-audit/scanners/#jax-checkpoint-scanner
• PyTorch (Stable Diffusion) -https://huggingface.co/docs/diffusers/v0.28.2/en/using-diffusers/other-formats#pytorch-ckpt

Такие нюансы создают сложности для сканера, это и оказалось причиной пропуска опасных моделей'etwithin/ckpt-scanner-bypass-poc', 'etwithin/diffusers-ckpt-ace-poc'.

Изучим репозиторий'etwithin/diffusers-ckpt-ace-poc'более подробно и для начала взглянем на результаты его проверок в самом HF:

Как видно, опасным является не весь репозиторий, а только один файл. Многие ML-модели хранятся внутри архивов, поэтому и откроем его архиватором:

Внезапно – внутри Pickle, который должен без проблем сканироваться как при помощи ModelAudit, так и многими другими инструментами.

Начнем с ModelAudit (версия 0.2.28) – ниже представлены результаты сканированияdata.pkl:

Сразу 4 критических сработки, которые изначально сканер пропустил, потому что просто не применил проверки, соответствующие ZIP-архивам (хотя подходящие проверки уже встроены в инструмент).

Получается у нас есть Pickle файл, который ModelAudit подсвечивает несколькими критическими ошибками. Но может это просто очередные FP и вообще какая именно зловредная логика в него заложена?

С этим нам поможет Fickling – он помимо проверки Pickle файлов позволяет произвести символическую десериализацию с последующей декомпиляцией (другие особенности Fickling описал впредыдущей статье):

По результатам декомпиляции видно, что этот файл при десериализации импортирует функциюsystemдля выполнения команд в системной оболочке из модуляposixи выполняет bash-скрипт, перезаписывающий файл расположенный по пути/tmp/diffusers_ace_proof.txt. Такая полезная нагрузка представлена просто как PoC, естественно на ее месте мог быть любой другой скрипт, с более интересной и опасной механикой работы.

Подведем промежуточные итоги:

• Все отобранные модели, которые были помечены опасными на Hugging Face сканер ModelAudit в версии 0.2.31 тоже рассчитал как опасные
• Для ModelAudit в процессе сканирования могут вызывать сложности расширения, имеющие разные значения в зависимости от контекста
• 26 моделей прошли все встроенные в Hugging Face проверки, но ModelAudit пометил их опасными

ModelAudit сигнализирует об опасности, но HuggingFace пропускает

Рассмотрим теперь те случаи, когда только ModelAudit посчитал модель опасной и для краткости сфокусируемся исключительно на тех моделях, которые получили хотя бы одну сработку критического уровня, к таковым относятся следующие модели:

Набравшись опыта, анализ этих моделей я начал с пересканирования актуальной версией ModelAudit, ожидая увидеть в результатах как минимум то же или даже возросшее число критических сработок, но по факту одна из моделей даже утратила свою единственную сработку и теперь по версии и ModelAudit, и Hugging Face модель отмечается безопасной.

treforbenbow/tensorrt-engine-rce-pocПосле изучения кода стало ясно – в более старых версиях в сканер.\modelaudit\scanners\tensorrt_scanner.pyбыла заложена довольно примитивная логика проверки вхожденияпаттернов в виде строкв единый,считанный из файла набор данных:

После обновленийизменились паттерны(вероятно такие проверки были слишком "шумными") иих поисктеперь производится по отдельным строкам.

Накладывая новую логику сканирования на модельtreforbenbow/tensorrt-engine-rce-pocвыяснилось, что среди прочих полученных из файла строк оказались следующие:"TensorRT Engine RCE PoC - Code executed via embedded plugin LoadLibrary()\n", "PID: %d\n", "\n[!] TensorRT RCE PoC: Arbitrary code executed via embedded plugin!\n". На них сканер в новой версии не срабатывает, в отличии от предшествующей версии.

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

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

В документации посвязанному сканерунет заявлений о детектировании вложенных.dllмоделей, но зато прописан поиск вложенных разделяемых библиотек (к которым относится и.dll) с фокусом на линуксовые.so:

Вдобавокполитиказапрещает открывать публичные "GitHub issue" для исправления недостатков:

Do not open a public GitHub issue.Public disclosure of unpatched vulnerabilities puts all ModelAudit users at risk. If this happens, maintainers may close the issue, redact sensitive details when possible, and redirect you to private reporting channels.

Нельзя – так нельзя. Не отступая от правил заполняю отчет по найденной уязвимости и наблюдаю за развитием событий. Через какое-то время появилось исправление –CHANGELOG.md.

Мне показались интересной первая реакция на отчет по уязвимости – после его отправки ботmldangelo-oai(ботом его считаю судя по суффиксу-oaiи количеству коммитов) создал приватную ветку в репозитории modelaudit и сам сгенерировал исправления. Другой агент начал проверку, но она завершилось ошибкой:

Есть ли вообще люди в репозитории ModelAudit? Открываемстраницу с дашбордомпо количеству коммитов за последний месяц и видим:

mldangelo- это GitHub аккаунт сооснователя и технического директора Promptfoo (ModelAudit является компонентом Promptfoo) Майкла Д'Анджело, по косвенным признакам складывается впечатление, чтоmldangelo-oaiявляется аккаунтом кодинг-агента Майкла. Все остальные аккаунты из топ-8 тоже подобны ботам/агентам от разных провайдеров.

Оказывается ModelAudit больше поддерживается различными агентами, чем людьми и при этом является мощным конкурентом для аналогичных сканеров с открытым исходным кодом. Увидев такой уровень использования различных AI-агентов, я озадачился изучением способов их оркестрации, первыми заметками буду делиться в своем tg-каналеBorZaseka.

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

AgentRen/hdf5-h5hl-fl-deserialize-hbo-pocИз описания репозитория модели:

This repo contains a malicious HDF5 file (malicious.h5) associated with upstream HDFGroup/hdf5 issue#5382(reported againstv1.14.6): heap-buffer-overflow inH5HL__fl_deserialize.

Вывод - это True Positive сработка 🗿

Остальные модели на самом деле и так были отмечены опасными на HF, ошибка оказалась в моем алгоритме получения результатов проверок моделей из Hugging Face.

Итоги сравнения результатов сканирования ModelAudit и с встроенными в HF проверкамиЕсли учесть все ложноотрицательные сработки ModelAudit исправленные в новых версиях вместе с теми, которые по ошибке не доносятся из HF, то получим следующую матрицу:

Как видно, все модели, которые были отмечены опасными по итогу встроенных в HF проверок так же оценены и сканером ModelAudit, помимо этого есть 17 моделей, которые по версии ModelAudit имеют хотя бы одну опасную сработку (info/warning/critical) и не имеют ни одного предупреждения от Hugging Face.

Коротко и честно:

Не так я себе всё представлял, когда мы начинали

И правда ведь, начиналось всё это, как казалось, небольшое исследование с довольно простой идеи – давайте возьмем сканер который забыли интегрировать в Hugging Face и просканируем им тонну-другую ML-моделей, найдем множество зловредных и вместе ужаснемся.

Далее стало ясно – либо ModelAudit слеп в той же степени как и стандартные проверки в Hugging Face, либо действительно опасных моделей не так уж и много. Эксперименты были доработаны, в качестве целей выбраны наиболее подверженные риску форматы хранения, но все равно большинство сработок оказались ложноположительными, пришлось анализировать их. Впрочем это тоже результат.

Разбирать ложные сработки стало скучно, а в памяти изпервой статьивсе еще держалась мысль – ModelAudit обойти сложнее всего. Тогда сравним его с чем-то аналогичным и ответим на вопрос - можно ли обойтись всего одним инструментом, решительно закрыв им основные риски?

Из этого этапа я сделал следующие выводы:

• ModelAudit в преобладающем числе случаев находит сработки в тех моделях, которые были отмечены опасными другими инструментами, генерируемые им предупреждения легко интерпретируются и даже позволяют найти соответствующий исходный код связанной проверки
• Глубокое сравнение артефактов работы двух сложных механизмов, выполняющих одну функцию, позволяет по отклонениям довольно легко находить неочевидные недостатки в работе этих механизмов, даже без предварительного погружения в их устройство
• Всё кончено - сканеры ML-моделей модифицируются и поддерживаются теми же моделями

P.S.: Выражаю благодарность за помощь в доработке статьи Сабрине Садиех, автору каналаData Blog