Критическая уязвимость в node-netmask затрагивает 279 тысяч приложений

Критическая уязвимость в node-netmask затрагивает 279 тысяч приложений

Критическая уязвимость в node-netmask затрагивает 279 тысяч приложений

В популярном npm-пакете node-netmask выявлена уязвимость, позволяющая обойти ограничение доступа к IP-адресам и провести атаку SSRF, RFI или LFI на приложение на базе Node.js. Проблема устранена с выпуском версии 2 продукта.

Библиотека netmask выполняет парсинг IP-адресов при обращении к сетевым ресурсам через приложение. На этот компонент полагаются свыше 279 тыс. проектов на GitHub; из репозитория npm его еженедельно скачивают по 3 млн раз и более.

Уязвимость в netmask, получившая идентификатор CVE-2021-28918, вызвана ошибкой в реализации проверки входных данных и проявляется при обработке IP-адресов смешанного формата.

Согласно спецификациям IETF, адреса IPv4 в текстовом виде могут быть представлены в различных форматах, в том числе в десятичном и восьмеричном. В последнем случае строковое значение адреса начинается с нуля — например, 0150.0024.0073.0321, что соответствует более привычному 104.20.59.209. Основные браузеры обычно отслеживают префикс «0» в адресной строке и автоматически совершают перевод IP-адреса в десятичный формат.

Как оказалось, netmask эту особенность не учитывает и попросту отбрасывает начальный 0, обрабатывая все части адреса как десятичные числа. Злоумышленник может, например, запросить ресурс, указав IP-адрес как 0177.0.0.1 (эквивалентно 127.0.0.1 — кольцевому адресу, возвращающему к локальному хост-компьютеру), и уязвимый модуль обработает его как внешний адрес 177.0.0.1. В итоге использующее netmask приложение не уловит тождества 0177.0.0.1 и 127.0.0.1 и загрузит ресурс в обход возможных запретов.

Точно так же при обращении к приложению на базе Node.js автор атаки может указать localhost-адрес как 0127.0.0.1 (соответствует десятичному 87.0.0.1). Модуль netmask обработает его как публичный 127.0.0.1, и искомый доступ будет получен.

 

Уязвимость в netmask позволяет также обойти проверку разрешений на доступ к интранет-адресам, VPN, контейнерам и узлам локальной сети путем ввода IP-адреса 012.0.0.1 (10.0.0.1), который netmask воспримет как 12.0.0.1 (публичный).

Обнаружившие проблему исследователи отметили, что она «катастрофична», так как возможность манипуляции значениями IP-адресов на уровне ввода грозит атаками типа RFI (Remote File Inclusion, динамическое подключение файлов с других серверов), LFI (Local File Inclusion, включение в цепочку выполнения локальных файлов) и SSRF (подмена адресов на стороне сервера).

Патч для netmask вышел десять дней назад в составе сборки 2.0.0 пакета; разработчикам приложений настоятельно рекомендуется обновить зависимости в коде.

AM LiveПодписывайтесь на канал "AM Live" в Telegram, чтобы первыми узнавать о главных событиях и предстоящих мероприятиях по информационной безопасности.

В Chrome для Android тестируют выдачу сайтам только примерной геолокации

Разработчики Android-версии Chrome тестируют более умный и аккуратный способ делиться геолокацией — теперь браузер может выдавать сайтам не точные координаты, а только примерное местоположение. Это не связано с системными настройками Android для приложений: речь идёт о новом уровне контроля именно над веб-сайтами.

Новую опцию для выдачи неточной геолокации отметили в версии Chrome 142.0.7444.171.

Она автоматически появилась у одного из тестировщиков, хотя другие не заметили нововведения, что намекает на A/B-тестирование. То есть Google пока экспериментирует с обновлённым диалогом разрешений.

Сегодня Chrome для Android получает доступ к точной геолокации через настройки приложения: достаточно зажать иконку браузера, открыть «О приложении», затем «Разрешения» → «Местоположение» и включить параметр «Использовать точное местоположение».

 

Можно и вовсе его отключить — тогда Chrome будет работать только с примерной локацией. Но такой подход ломает сайты, которым действительно нужны точные координаты — например, сервисы навигации.

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

 

Таким образом, сайты, которым достаточно знать ваш район, не получат конкретных координат, а тем, кто действительно требует точных данных, придётся запрашивать доступ отдельно.

Android давно поддерживает два уровня отслеживания геолокации: примерный (радиус около 3 кв. км) и точный. Многие приложения используют это через системные диалоги разрешений, но Chrome до сих пор не применял такую логику к веб-ресурсам.

Теперь это меняется. Функцию можно включить вручную через chrome://flags — именно там Google хранит экспериментальные настройки. После активации выбор «Примерное местоположение» ограничит сайты только вашей приблизительной зоной.

 

 

Google пока не объявляла о нововведении официально и не раскрывала сроки широкого запуска. Но раз эксперимент уже идёт, пользователи Android могут довольно скоро получить более гибкий и приватный контроль над тем, какие сайты видят их точное местоположение.

Пару недель назад мы сообщали, что в Android 16 появилась новая функция density-based coarse location — «приблизительное местоположение на основе плотности населения». Она работает просто: система проверяет, насколько густо заселён район, и если рядом мало людей, то делает координаты ещё более размытыми.

AM LiveПодписывайтесь на канал "AM Live" в Telegram, чтобы первыми узнавать о главных событиях и предстоящих мероприятиях по информационной безопасности.

RSS: Новости на портале Anti-Malware.ru