Комментарии 9
Я "мимо проходил" и на js никогда не разрабатывал. Но когда читаю про очередную подобную атаку, всё время задаюсь вопросом: "зачем в специализированном пакетном менеджере есть возможность запускать скрипты?" Почему он не сводится к копированию файлов и обновлению метаданных?
Потому что некоторые пакеты могут требовать компиляции их отдельных компонентов под конкретную ОС.
Казалось бы, что для этого могла бы существовать команда самого пакетного менеджера "COMPILE", вместо такой гибкости, как произвольный скрипт. Хотя, признаюсь, я плохо понимаю, что такое компиляция в js.
всегда можно в процесс компиляции встроить (лишнее) нужное тогда :))
Не представляю как компиляция может встроить то, чего не было в исходниках. Это более-менее стандартный процесс, который не предполагает хождения в сеть: транспиляция, минификация и т.п. Он также не предполагает выполнение кода пакета на сборочной машине.
Во многих же подобных атаках вижу схему, что postinstall пошёл, скачал и запустил что-то нехорошее. Понятно, что это нехорошее может быть и в самих исходниках, но поверхность атаки становится меньше, её легче отследить и она проявится в момент установки пакета
тут как говорится "так исторически сложилось", многие либы сразу тянут за собой бинарники, чтобы работать под конкретную ос, или патчат зависимости за собой, чтобы конфликтов не было в проекте , или вообще тебе файлы в проект генерировать при установке. Мы платим большой гибкостью, большим количеством дыр. Но благо кроме стандартных пакетных менеджеров, мы имеем условный pnpm, который позволяет максимально минимизировать риски
Так корень-то проблемы не в этом. Даже если у пакетного менеджера и нет будет возможности запускать скрипты, то вредоносный код можно с таким же успехом внедрить и в код самого пакета - просто он сработает не на этапе установки зависимостей, а при запуске проекта. Проблема в самом современном подходе к управлению зависимостями. И она характерна не только для экосистемы JS - я недавно начал писать небольшой пет-проект на Rust. Добавил 2 (правда, достаточно крупных) зависимости в Cargo,toml, запустил сборку и в итоге при сборке cargo мне скачал и скомпилировал больше 200 крейтов. Что в большинстве из них и кто их автор - понятия не имею. Достаточно компрометации одного из них - и все.
Не понял только откуда пакеты собирались. Напрямую со своей ветки или таки прошёл некий релизный цикл с PR и CR до основной ветки?
Атака на axios в npm: как один захваченный аккаунт поставил под угрозу миллионы JavaScript-проектов