Популярная библиотека кода NPM под названием Pac-Resolver была обновлена для устранения серьезной уязвимости, связанной с удаленным выполнением кода. Разработчики, включившие пакет в свои приложения, должны обязательно обновить свои зависимости, чтобы избавиться от ошибки, и предоставить пользователям необходимые обновления для их защиты.
По сути, любое приложение, использующее уязвимый код для обработки интернет-прокси, потенциально может в конечном итоге выполнить вредоносный код, если ему будет предоставлена информация о конфигурации прокси-сервера, которая может поступать из нескольких источников.
Во вторник Тим Перри, который создает инструмент разработчика под названием HTTP Toolkit, объяснил, как он обнаружил недостаток, обнаруженный около недели назад как CVE-2021-23406, при добавлении поддержки прокси в свое программное обеспечение.
Pac-Resolver, загружаемый более трех миллионов раз в неделю, обеспечивает поддержку файлов «Proxy Auto-Config» (PAC), которые сообщают HTTP-клиентам, какой прокси использовать для данного имени хоста.
«Файлы PAC предоставляют способ распространять сложные правила прокси в виде единого файла, который сопоставляет множество URL-адресов с разными прокси», – объясняет Перри в информационном бюллетене. «Они широко используются в корпоративных средах и поэтому часто нуждаются в поддержке в любом программном обеспечении, которое может работать в корпоративной среде».
Эти файлы могут распространяться с локального сетевого сервера, через HTTP или с удаленного сервера. Этот метод достаточно распространен, поэтому существует стандарт под названием WPAD (протокол автоматического обнаружения веб-прокси) для автоматизации обнаружения файлов PAC.
Заметив, что файлы PAC восходят к Netscape Navigator 2.0 в 1996 году, Перри объясняет: «Это файл JavaScript, который вы должны выполнить для подключения к Интернету, который загружается удаленно, часто небезопасно и / или из места, которое может быть выбрано незаметно для пользователя. в вашей локальной сети. 1996 год был действительно более простым временем. Что могло пойти не так? “
Что ж, можно было бы создать изолированную функцию с использованием модуля vm в Node.js, который включает в свою документацию следующее предупреждение: «Модуль vm не является механизмом безопасности. Не используйте его для запуска ненадежного кода».
Проблема модуля vm, как объясняет Перри, заключается в том, что если вы включите такую функцию в код JavaScript файла PAC …
// Here's the real PAC function:
function FindProxyForURL(url, host) {
return "DIRECT";
}
// And here's some bonus arbitrary code:
const f = this.constructor.constructor(`
// Here, we're running outside the sandbox!
console.log('Read system env vars:', process.env);
console.log('!!! PAC file is running arbitrary code !!!');
process.exit(1); // Kill the HTTP client process remotely
// ...steal data, break things, etc etc etc
`);
f();
…this указывает на vm.runInContext, который создает песочницу, созданную из параметра объекта во внешней среде Node.js. Это дает возможность запускать код вне песочницы.
Но предположим, что вы пропустили это предупреждение о модуле. Затем, как создатель Pac-Resolver, который используется в Pac-Proxy-Agent, который, в свою очередь, используется в Proxy-Agent, вы должны пересмотреть свой код и выпустить исправление.
«К сожалению, Pac-Proxy-Agent не корректно выполняет сценарии PAC в песочнице», – говорит Перри, добавляя, что библиотека полагается на модули Pac-Resolver и Degenerator для создания функции PAC. «Каждый раз, когда вы делаете запрос с помощью файла PAC, он может запускать произвольный код и делать что угодно в вашей системе. Если он злонамеренный, у вас большие проблемы».
Любой, кто использует версию Pac-Resolver, Pac-Proxy-Agent или Proxy-Agent до версии 5.0, потенциально уязвим для загрузки вредоносного файла PAC.
Как это можно использовать? Конфигурационный файл с ловушкой может быть обслужен сетевым администратором-мошенником для взлома устройства, или кто-то может перехватить небезопасную выборку файла и переписать его, чтобы добиться удаленного выполнения кода. Фактически, Перри перечислил несколько маршрутов в своей статье:
Исправление, доступное в v5 + любого из этих пакетов, было сделано дальше по дереву зависимостей в пакете Degenerator Pac-Resolver.
Перри рассматривает этот инцидент как свидетельство ценности проверки зависимостей вашего кода.
«Во многих случаях, особенно для больших приложений со сложными зависимостями, это невозможно для всех зависимостей, но, по крайней мере, просмотр ваших наиболее чувствительных зависимостей (например, автоматическая настройка прокси-сервера) поможет вам выявить эти непреднамеренные ошибки и помочь исправить их для всех», он сказал. ®
