Привет Хабр!
На фоне громких новостей об очередных атаках на цепочку поставки открытого программного обеспечения защитники фокусируются на вопросе проверки этих самых пакетов и выстраивании слоев анализа: от стадии загрузки компонента в контур организации до многоуровневых проверок в рамках композиционного анализа. И, конечно же, не забывают про применение антивируса. Но в этом вопросе также заметную роль играет инфраструктура: собственная и внешняя, а именно пакетные менеджеры и реестры пакетов (пакетные индексы). О ней забывать нельзя.
Мы продолжаем делиться полезными материалами в части защиты цепочки поставки с точки зрения инфраструктуры и подготовили адаптированный перевод статьи Эндрю Несбитта “Package Manager Threat Models”. Автор раскладывает модель угроз для клиентской и стороны реестров пакетов, что крайне важно для комплексного видения проблематики.
P.S. В статье приводятся многочисленные отсылки к статье “Package Manager CWEs”, которая также заслуживает внимания, и мы обязательно выпустим её перевод.
Слово Эндрю Несбитту.
Я уже писал о багах, которые заводят на пакетные менеджеры: обход путей при распаковке архива (path traversal), внедрение аргументов в Git-драйвер, XSS в рендерере README на стороне реестра пакетов. Такие проблемы можно найти, прочитав код: указать конкретную строку и исправить патчем.
Этот пост — вторая половина картины. Механизмы, описанные ниже, работают ровно так, как задумано, поэтому CVE на них никто не заводит. При этом именно из них выросли почти все знаменитые инциденты в цепочке поставки. В случаях event-stream, ua-parser-js, left-pad и xz пакетный менеджер делал именно то, для чего был создан.
Если моя предыдущая статья была списком паттернов, которые можно искать в коде, то это — список вопросов, на которые нужно ответить развернуто. Результат такой работы — несколько абзацев по каждому разделу с описанием того, что инструмент делает на самом деле. Ответы сильно отличаются от одного инструмента к другому, и большинство из них нигде не записано, кроме исходного кода.
1. Клиент
Выполнение кода при установке
Основное архитектурное решение, используемое в пакетном менеджере, на котором выстраивается значительная часть известных инцидентов, — запускается ли при установке код из пакета: на машине пользователя, с его правами, с доступом к его окружению, еще до того, как пользователь увидел хотя бы одну строку этого кода.
Большинство языковых пакетных менеджеров по умолчанию так и делают. npm запускает postinstall, pip запускает setup.py, Cargo компилирует и выполняет build.rs, gem собирает нативные расширения. У этого механизма есть причины: фрагменты кода на С действительно нужно как-то компилировать. Но это тот же механизм, который лежит в основе event-stream, ua-parser-js, node-ipc, colors и каждого install-script-червя.
Для модели угроз конкретного пакетного менеджера здесь важно зафиксировать несколько вещей: какие установочные хуки существуют, какие запускаются по умолчанию, срабатывают ли они для транзитивных зависимостей, от имени какого пользователя выполняются, есть ли параметр для отключения и остается ли инструмент работоспособным после его включения. Отдельно стоит пройтись по глобальной установке, dev-зависимостям и необязательным зависимостям: в некоторых экосистемах у них отличаются права выполнения и набор запускаемых хуков. Go и Deno интересны как ориентиры именно потому, что они ответили “ничего не запускается” и спроектировали архитектуру вокруг этого ограничения.
Выполнение кода до установки
Это менее очевидная версия того же вопроса. В представлении пользователя опасная команда — это install, а lock, audit, outdated и команды получения метаданных безопасны. Каталог CVE из прошлого поста показывает, где эта модель ломается случайно; этот раздел — о том, где она ломается по замыслу.
setup.py — это Python-программа, и долгое время получение номера версии из нее означало ее запуск. build.gradle — это Groovy-программа, и разрешение графа зависимостей означает ее выполнение. Форматы манифестов, которые являются данными — TOML, JSON, строго ограниченное подмножество YAML, — проводят здесь жесткую границу. Форматы манифестов, которые являются программами, такую границу провести не могут. Нужно понять, какие команды осторожный пользователь может запускать в рабочей копии недоверенного репозитория. Для нескольких инструментов честный ответ — никакие.
Гарантии lockfile по дизайну
В предыдущем посте речь шла о багах lockfile: кодовых путях, которые игнорируют lockfile там, где не должны. Но главный вопрос заключается в том, что lockfile вообще обещает.
Lockfile, который фиксирует хэш содержимого (go.sum, package-lock.json, Cargo.lock начиная с 1.0), гарантирует, что вы получите именно те байты, которые были зафиксированы. Другие lockfile фиксируют только имя и версию и доверяют реестру пакетов в том, что он продолжит отдавать одни и те же байты для этой пары (Gemfile.lock, классический yarn.lock). Поверх этого у нескольких инструментов есть две команды установки: одна строго соблюдает lockfile, другая может его обновлять. Пара, с которой большинство пользователей сталкивается в первую очередь, — npm install и npm ci.
Самое лучшее решение здесь у Go: база контрольных сумм, публичный append-only журнал хэшей всех версий модулей, с которым клиент сверяется по умолчанию. Поэтому ни прокси, ни исходный источник не могут задним числом изменить то, во что разрешается версия. Эта база находится вне клиента и вне реестра, и именно поэтому она интересна.
Нужно зафиксировать, что именно закрепляется, какие команды это соблюдают и использует ли CI-шаблон строгую команду.
Однозначная идентификация имени пакета
Правила, по которым два имени пакета считаются одинаковыми, различаются от одного реестра пакетов к другому. Почти все при этом что-то нормализуют: регистр, дефис против подчеркивания и точки, ширину Unicode-символов. Уже не раз случалось так, что логика пакетного менеджера расходилась с логикой реестра пакетов в том, какие именно правила применять. В пространстве между двумя нормализаторами один пакет может подменить другой. Нужно описать правила нормализации на стороне клиента и подтвердить, что они в точности совпадают с правилами реестра, включая имена, которые приходят не из пользовательского ввода, а из lockfile или транзитивного манифеста.
Разрешение зависимостей из нескольких источников
Большинство клиентов можно настроить на работу с несколькими источниками: публичный реестр пакетов плюс приватный, основной источник плюс зеркало. Исследование dependency confusion 2021 года показало, что происходит, когда одно и то же имя существует в обоих источниках, а резолвер выбирает пакет по версии, а не по источнику. Атакующий регистрирует имя внутреннего пакета в публичном реестре с более высокой версией, и резолвер предпочитает его. Поведение pip с --extra-index-url, где все индексы считаются равнозначными, задокументировано, и CVE, заведенная на это поведение, была оспорена именно по этой причине.
Нужно определить, что делает резолвер, когда имя можно сопоставить из нескольких настроенных источников: выбирает максимальную версию среди всех, берет первый источник, где пакет найден, требует явной привязки источника к зависимости или отказывается продолжать. Затем нужно понять, может ли источник, добавленный ради одной зависимости, удовлетворять другие, и записывает ли lockfile, откуда фактически пришел каждый пакет.
2. Реестр пакетов
Распределение имен
“Кто первым занял, того и имя” — правило по умолчанию почти для каждого публичного реестра пакетов. Это значит, что безопасность обращения к имени зависит от того, остается ли человек, случайно зарегистрировавший его в 2011 году, добросовестным участником в 2026 году. Исправить это без разрушения того, что делает открытые реестры пакетов полезными, невозможно. Но правила для крайних случаев сильно различаются и имеют большое значение.
Нужно выяснить, можно ли передать имя и кто принимает такое решение; что происходит с именем, когда владелец удаляет аккаунт; можно ли заново зарегистрировать удаленное имя и через какое время. Последнее — поверхность для атаки “revival hijack”: если реестр разрешает немедленно регистрировать освободившиеся имена, он фактически отдает атакующему каждый пакет, чей мейнтейнер однажды на эмоциях удалит аккаунт. Пространства имен с областью или префиксом организации (@scope/pkg, group:artifact) уменьшают проблему, и их стоит отметить там, где они есть.
Схожая атака — typosquatting: имена, которые для реестра разные, а для человека выглядят одинаково. Это уже показывали на всех крупных реестрах, и архитектурный вопрос здесь в том, делает ли реестр что-нибудь при публикации: оценивает визуальное сходство с существующими именами, резервирует префиксы, блокирует схожие до степени смешения символы Unicode или не делает ничего.
Жизненный цикл мейнтейнера
Инцидент с xz — эталонный пример: ничего не взломали, нового мейнтейнера добавили стандартным процессом, и доверие пользователей к исходному автору незаметно перешло к человеку с другими намерениями. Пакетный менеджер не может решить проблему кампании социальной инженерии, но он определяет, насколько видимой будет такая передача прав.
Нужно установить, как мейнтейнер добавляется к пакету: через приглашение, запрос, автоматически через членство в организации. Получают ли существующие пользователи какой-либо сигнал, когда список меняется. Может ли новый мейнтейнер публиковать сразу или есть задержка. Есть ли роли: публикация, администрирование, чтение. Большинство реестров считают всех мейнтейнеров равными и никого не уведомляют при добавлении нового; это тоже нужно записать.
Состав мейнтейнеров может измениться и так, что реестр пакетов ничего не зафиксирует, потому что в большинстве реестров личность мейнтейнера в конечном счете сводится к контролю над email-адресом. Сброс пароля уходит на адрес, указанный в аккаунте, и если этот адрес находится на домене, который с тех пор истек, регистрации домена достаточно, чтобы захватить аккаунт. Нужно выяснить, на чем держится восстановление аккаунта: на одном адресе, втором факторе, аппаратном ключе; проверяется ли этот адрес повторно; может ли давно неактивный аккаунт выпустить новый релиз, имея только ссылку для сброса пароля.
Неизменяемость опубликованных версий
После публикации foo 1.2.3 байты не должны меняться никогда. В большинстве современных реестров это действительно так, хотя путь к этому правилу прошел через left-pad, а особые случаи все еще стоит проверять.
Нужно проверить, можно ли удалить версию; если да, становится ли пара имя+версия снова доступной или навсегда помечается как занятая. Что означает yank: версия скрыта из разрешения зависимостей, но все еще устанавливается по lockfile, или она действительно исчезает. Есть ли после публикации окно, в течение которого версию можно незаметно заменить. Отличаются ли ответы для CDN, API и зеркал. Реестр, который разрешает повторную публикацию удаленной версии, — это реестр, где lockfile, фиксирующий только версию, ничего не гарантирует.
Происхождение от исходного кода до артефакта
На протяжении большей части истории пакетных реестров не было способа проверить связь между tarball в реестре и репозиторием, к которому он якобы относится. Поле repository в манифесте — это строка, которую ввел публикующий. Версия 3.0.1 в реестре и тег v3.0.1 на GitHub связаны только соглашением.
Ситуация меняется. Trusted publishing в PyPI, RubyGems, crates.io, npm и других реестрах привязывает учетные данные публикации к конкретному CI-workflow, а attestations происхождения записывают, какой коммит и какой workflow создали артефакт, причем так, чтобы клиент мог это проверить. Нужно отметить, поддерживает ли реестр такой механизм, показывает ли это клиент и какая примерно доля популярных пакетов реально им пользуется. Опциональная аттестация у трех процентов пакетов дает совершенно иные гарантии по сравнению с обязательной проверкой.
Минимально достаточные учетные данные для публикации
Токен публикации — это то, что атакующие вытаскивают из CI-логов, выманивают у мейнтейнеров фишингом и находят в старых коммитах. Поэтому его форма важнее почти всего остального на стороне реестра. В предыдущем посте речь шла о токенах, у которых баги в проверке областей действия; здесь вопрос в том, какие области действия вообще существуют.
Нужно разложить это по следующим параметрам:
область действия — один пакет или все, что владелец может публиковать;
возможности — только публикация или еще добавление мейнтейнеров и изменение настроек;
срок действия — обязательный, опциональный или отсутствует;
есть ли у требования 2FA при публикации обход через токен автоматизации и насколько узким можно сделать этот обход.
Затем — что происходит при утечке: есть ли у токена узнаваемый префикс, подключен ли реестр к secret scanners, которые автоматически его отзовут, или это ничем не размеченная строка, которая лежит в публичном коммите до первого использования. В реестре, где единственные учетные данные — это API-ключ, равный сессии и не имеющий срока действия, одна утекшая переменная CI означает потерю всего аккаунта навсегда. В реестре с короткоживущими OIDC-токенами, обменянными на право публикации одного пакета, это максимум один плохой релиз.
Радиус поражения и обнаружение
Последний вопрос — что происходит после компрометации, а не до нее. Если аккаунт мейнтейнера публикует вредоносную версию, насколько далеко она успевает распространиться, прежде чем кто-то в принципе может это заметить, и что реестр пакетов дает людям, которые расследуют инцидент.
Нужно искать обнаружение аномалий при публикации: новый мейнтейнер, давно неактивный пакет, версия опубликована из новой страны. Нужен способ пометить опубликованную версию как вредоносную так, чтобы клиенты отказывались ее устанавливать, а не просто скрывали из разрешения зависимостей. Нужен аудит лог: кто, что и откуда опубликовал. Нужен механизм, позволяющий реестру оповещать зависимые проекты о том, что они установили пакет, который позже был изъят. Все это не предотвращает компрометацию, но разница между “отозвали за 20 минут со списком затронутых установок” и “заметила третья сторона через три недели” в основном сводится к тому, существуют ли такие механизмы.
3. Собственная цепочка поставки инструмента
Обе половины применяются рекурсивно. Клиент — это программа с зависимостями, обычно из той же экосистемы, которую он обслуживает: npm — npm-пакет, Bundler — gem, Cargo построен с помощью Cargo. Реестр пакетов — приложение с манифестом, который часто разрешается через ту же экосистему: у rubygems.org есть Gemfile, у crates.io — Cargo.toml. Скомпрометированный пакет в любом из этих деревьев означает выполнение кода внутри компонента, которому вынуждена доверять вся остальная экосистема.
Поэтому вопросы выше применяются и к собственным манифестам инструмента. Как обрабатываются зависимости клиента и реестра: включены ли они прямо в дерево исходников, закреплены ли хэшем содержимого в закоммиченном lockfile или разрешаются во время сборки из живого реестра. pip включает все зависимости в pip._vendor, чтобы разорвать этот цикл на стороне клиента. На стороне реестра стоит более острый вопрос: есть ли в деплойном дереве зависимостей что-то, что запускает хуки во время установки? Потому что именно в этот момент зависимость становится кодом на сервере, где находятся учетные данные публикации всей экосистемы.
Проект, который письменно ответил на все эти вопросы, уже имеет что-то близкое к опубликованной модели угроз. Некоторые уже это делают: страница npm об угрозах и мерах снижения риска покрывает большую часть этого списка со стороны мейнтейнера, а OpenSSF Principles for Package Repository Security описывает половину, связанную с реестром пакетов, как модель зрелости для операторов. Каталог CVE из предыдущего поста будет продолжать расти по мере того, как баги будут находить и исправлять. Этот список в основном расти не будет. И именно поэтому ответы стоит записывать там, где пользователи смогут их прочитать, а не оставлять неявными в исходном коде.