OpenBSD перешёл на обязательное использование механизма защиты W^X

OpenBSD перешёл на обязательное использование механизма защиты W^X

OpenBSD перешёл на обязательное использование механизма защиты W^X

Проект OpenBSD перешёл на обязательное применение механизма защиты памяти W^X (Write XOR Execute), суть которого в том, что страницы памяти процесса не могут быть одновременно доступны на запись и исполнение.

Таким образом, код может быть исполнен только после запрещения записи, а запись в страницу памяти возможна только после запрета исполнения. Механизм W^X помогает защитить приложения в пространстве пользователя от типовых атак, осуществляемых через переполнение буфера, в том числе от переполнений стека (записанный за пределы буфер код не может быть исполнен), сообщает opennet.ru.

Традиционно в Unix при маппинге памяти допускается модель "W|X", позволяющая одновременно осуществлять и запись, и исполнение, что является порочной практикой с позиции обеспечения безопасности. В OpenBSD отныне такая модель переведена в категорию недопустимых (при попытке использования будет выведена ошибка) и обязательно требуется использование только механизма "W^X".

Обход запрета "W^X" может быть осуществлён только через монтирование ФС (ffs/nfs) со специальным флагом "wxallowed", который рекомендуется использовать для монтирования /usr/local, так как некоторые сторонние программы пока не адаптированы для нормальной поддержки "W^X". Многие порты уже адаптированы для нормальной работы в режиме "W^X" или поддерживают его из коробки (например, Firefox), но с рядом крупных пакетов пока наблюдаются проблемы, это касается JDK, GCC, Mono и Chromium.

Критическая дыра в популярных VPN-клиентах на базе VLESS раскрывает IP

Исследователь с ником runetfreedom утверждает, обнаружил критическую уязвимость сразу в нескольких популярных VLESS-клиентах для мобильных устройств. По словам автора, проблема позволяет обходить механизмы изоляции приложений и выявлять внешний IP-адрес используемого прокси.

Отдельно он выделил клиент Happ, который назвал особенно рискованным. При этом свои выводы автор сопроводил ссылкой на GitHub-репозиторий с демонстрационным эксплойтом (PoC).

По версии runetfreedom, уязвимость затрагивает целый ряд приложений, включая v2RayTun, V2BOX, v2rayNG, Hiddify, Exclave, Npv Tunnel, Neko Box и Happ. Исследователь уведомил разработчиков ещё 10 марта, но на момент публикации статьи, как утверждает автор, ни один клиент полностью проблему не закрыл.

Смысл претензии в том, что часть клиентов, по словам исследователя, поднимает локальный прокси без должной защиты, а это теоретически может открыть дорогу для нежелательного доступа со стороны других приложений на устройстве.

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

 

Самая жёсткая часть отчёта касается клиента Happ. Автор утверждает, что именно он оказался наиболее уязвимым и потенциально может раскрывать больше данных, чем другие приложения. Позже, в обновлении к публикации, runetfreedom написал, что Happ всё же согласился исправить обе уязвимости. Но в публично доступных источниках пока нет полноценного технического отчёта от разработчиков о том, когда именно выйдет патч и что именно будет закрыто. У Happ при этом есть публичный телеграм-чат, где обсуждается продукт.

Отдельно специалист связывает свои опасения с недавними публикациями о новых мерах против VPN. Ранее мы сообщали, что Минцифры обсуждает с крупнейшими площадками и операторами более жёсткие способы выявления пользователей с включёнными средствами обхода ограничений, а также методические рекомендации для бизнеса.

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