Hacker News Digest

Разработчик Chromium Брюс Доусон обнаружил, что VS Code течёт дескрипторы процессов: вместо того чтобы закрывать дескриптор после использования, он оставляет его открытым. Каждый незакрытый дескриптор «стоит» 64 КБ, и при длительной работе редактора это может привести к утечке гигабайтами памяти. Проблема была найдена и исправлена в течении пары дней после доклада, и в релизе 1.94 VS Code больше не течёт.

• VS Code и другие крупные редакторы из-за своего размера и сложности становятся мишенью для атак на цепочку поставок и уязвимостей.
• Участники обсуждают, что большие кодовые базы и многочисленные зависимости увеличивают риски.
• Появляется идея использовать ограничения по памяти для раннего обнаружения утечек и избытка функций.
• Некоторые участники выражают обеспокоенность по поводу того, что такие ограничения могут быть непрактичны в современных условиях.
• В целом, обсуждение подчеркивает важность минимизации поверхности атаки и управления рисками в экосистеме разработки.

Обнаружена первая вредоносная реализация MCP-сервера в дикой природе — пакет postmark-mcp, который с версии 1.0.16 тайно копирует все отправляемые письма на внешний сервер злоумышленника. Пакет скачивался 1500 раз в неделю и интегрировался в рабочие процессы разработчиков, получая полный доступ к почтовым данным, включая сбросы паролей, конфиденциальные документы и финансовые отчеты.

Атака основана на имперсонации: злоумышленник скопировал код официального репозитория Postmark, добавил скрытую строку BCC и опубликовал под тем же именем в npm. Уязвимость оставалась незамеченной, так как MCP-серверы работают вне периметра безопасности, обходя системы контроля DLP и инвентаризации активов. Это демонстрирует растущие риски supply-chain-атак через инструменты ИИ, которые получают привилегии без должной проверки.

• Участники обсуждают риски использования сторонних пакетов и инструментов, проводя параллели с историческими проблемами безопасности, такими как уязвимости в почтовых клиентах или SQL-инъекции.
• Высказываются предположения, что инцидент с пакетом postmark-mcp мог быть не злонамеренной атакой, а случайной ошибкой разработчика, оставившего отладочный код.
• Поднимается вопрос о доверии к ИИ-инструментам и MCP-серверам, которые получают чрезмерные права доступа к данным без должного контроля со стороны пользователей.
• Критикуется практика публикации статей, обработанных ИИ, что затрудняет восприятие и проверку фактов, а также общая культура безопасности в разработке, где скорость часто важнее надежности.
• Обсуждается ответственность платформ (например, npm) и необходимость более строгих правил для предотвращения подмены пакетов и supply chain-атак.

О нет, снова... Размышления об атаках на цепочку поставок NPM

Я долго откладывал эту статью — более года — но, как мы видим на этой неделе, пришло время снять покровы и сказать вслух:

В 2025 году Microsoft следует считать «плохим игроком» и угрозой для всех компаний, разрабатывающих программное обеспечение.

Конечно, если вы достаточно взрослые, чтобы помнить — это не первый раз...

Время — плоский круг

Мы снова здесь — в 2025 году Microsoft настолько всё испортили, что создали ещё больший риск, чем в 2000-х с их браузером, просто ничего не делая.

Изначально я начал писать этот пост во время инцидента с xz — изощрённой и долгосрочной попытки взять под контроль библиотеку, используемую в менеджерах пакетов большинства дистрибутивов Linux.

С тех пор произошло множество инцидентов, и конкретно NPM стал крупнейшим и самым простым способом распространения вредоносного ПО. Сначала большинство атак было направлено на кражу криптовалюты (поскольку техбро одержимы магическими электрическими деньгами и являются лёгкой добычей). Но теперь эти атаки на цепочку поставок нацелены на более критичные вещи, такие как токены и ключи доступа maintainers пакетов, как видно из инцидента с NX и теперь несколькими зависимостями, ежедневно используемыми тысячами разработчиков.

Опять же... это ничего нового в мире NPM.

Но так быть не должно было...

Мы прошли долгий путь, но никуда не ушли

У меня долгая история с NodeJS — примерно в 2010 году я начал работать над стартапом, и это было до того, как npm вообще появился.

В туманные дни 1990-х большинство проблем безопасности JavaScript не сильно касались бэкенда: это в основном была область Perl, PHP, Python и Java.

Однако веб был совсем другой историей.

В самые ранние дни Всемирной паутины был только один основной браузер, который все использовали: Netscape Navigator. Выпущенный в 1994 году, он был не просто браузером: на протяжении своей жизни он имел различные воплощения встроенного почтового клиента, календаря, HTML-редактора с FTP-браузером, а с плагинами мог воспроизводить медиафайлы, такие как Realplayer и MP3 (что я помню при его запуске), а также флеш-фильмы и игры. Именно здесь родился JavaScript.

Многие ранние сайты того времени были статичными — популярные инструменты для создания сайтов включали HotDog или Блокнот. Никаких навороченных IDE или фреймворков, только текстовый редактор, браузер и alert() для отладки.

Microsoft также вошла в игру с Internet Explorer — включённым в раннее DLC для Windows под названием «Plus! For Windows 95». В конечном итоге он стал программным обеспечением, на которое Microsoft поставила всю свою корпоративную стратегию (во многом как сегодня с ИИ).

Internet Explorer был встроен в каждый аспект Windows — сначала в 1995 году с Active Desktop, что продолжалось вплоть до Windows XP. С ним можно было встраивать фрейм на рабочий стол, а также документы Rich Text или электронные таблицы Excel. Он также был раздутым и багнутым — и с этим представлял две проблемы: огромный риск безопасности и обвинения в монополизации рынка браузеров.

Закон жёстко настиг Microsoft, и в 2001 году она проиграла — Microsoft было приказано разбить компанию, но апелляция отменила это решение.

• Участники критикуют экосистему npm за уязвимости в цепочке поставок и отсутствие безопасности по умолчанию, сравнивая её с другими менеджерами пакетов.
• Обсуждается роль крупных компаний (в частности, Microsoft как владельца npm) в решении проблем безопасности и их ответственность за состояние экосистемы.
• Предлагаются конкретные меры: обязательная 2FA, подписывание кода, политика задержки обновлений (cooldown), переход на альтернативы (pnpm), сканирование пакетов.
• Поднимается проблема эксплуатации труда добровольцев в open-source и недостаточного вклада коммерческих организаций в проекты, которые они используют.
• Отмечается, что культура JavaScript-разработки чрезмерно зависит от большого количества зависимостей, что увеличивает поверхность атаки.
• Указывается на необходимость более строгого контроля зависимостей, включая проверку кода и фиксирование версий (pinning).
• Некоторые участники считают, что фундаментальные изменения в экосистеме маловероятны, и рекомендуют индивидуальные меры защиты.