Администраторы серверов под управлением Linux могут получить возможность отключать уязвимую функцию в ядре операционной системы до тех пор, пока не будет готов патч для уязвимости нулевого дня, если это предложение разработчика и мейнтейнера ядра будет принято сообществом открытого исходного кода.
Идея «аварийного выключателя» (kill switch) для привилегированных операторов была предложена Сашей Левиным, выдающимся инженером Nvidia и одним из мейнтейнеров долгосрочных и стабильных веток ядра Linux, в качестве временной меры при обнаружении уязвимости в системе безопасности.
Как он отметил в недавнем сообщении, когда обнаруживается уязвимость, «парки машин остаются под угрозой до тех пор, пока не будет собран, распространен и загружен пропатченный образ ядра. Для многих подобных проблем простейшей мерой смягчения является прекращение вызовов ошибочной функции». В своем сообщении Левин и его коллега также представили предложенную версию аварийного выключателя для ядра.
«Для большинства пользователей, — подчеркнул Левин, — цена в виде того, что “это семейство сокетов перестанет работать на сегодня”, намного ниже, чем цена работы с известным уязвимым ядром до выхода исправления».
Это предложение прозвучало на фоне обнаружения нескольких критически важных уязвимостей в Linux, включая Copy Fail (CVE-2026-31431), логическую ошибку, позволяющую пользователям легко получить доступ уровня root, и Dirty Frag, которая использует слабости в обработке ядром Linux фрагментированных страниц памяти. Атака Dirty Frag объединяет две отдельные уязвимости, затрагивающие подсистему IPsec Encapsulating Security Payload (ESP) в Linux (CVE-2026-43284) и сетевой протокол RxRPC (CVE-2026-43500).
Пользователи форумов по безопасности против
Предложение вызвало ожесточенные споры среди специалистов по информационной безопасности. Например, на форуме Reddit r/cybersecurity его назвали «ужасной идеей», «нелепым», «абсолютно пугающим» и «слишком рискованным».
«Люди будут использовать аварийный выключатель вместо установки патчей», — возразил один из участников.
Участники также указали на недостатки предложенного кода. Один из них отметил, что аварийный выключатель будет отключать конкретную функцию, но при этом отключает точку входа самого высокого уровня, которая уже обрабатывает состояние «сбоя» для этой операции.
«Если вы знаете, как работает Linux, он вам не нужен», — добавил другой участник, который заявил, что в течение пары часов после выпуска эксплойта Dirty Drag он проанализировал код и подготовил меры по смягчению последствий. «Если вы не знаете, как работает Linux, — добавил он, — вам не следует использовать никакой аварийный выключатель».
Эксперты по Linux и безопасности настроены осторожно
«[Аварийный выключатель] хорош в теории, но я не думаю, что он ускорит переход к защите быстрее, чем то, с чем мы сталкиваемся сегодня, учитывая, что контроль изменений все равно должен тщательно тестироваться и управляться», — сказал Келман Мегу, технический директор канадской фирмы по реагированию на инциденты DeepCove CyberSecurity, в интервью CSO.
«Разработчику легко сказать: “Просто выгрузите этот модуль ядра”, но более сложная часть — это заверить бизнес в отсутствии влияния на сервисы. В таком случае я спрашиваю, зачем этот модуль вообще загружался, если он никогда не был нужен? Это похоже на пробел в моем процессе укрепления безопасности и сборки», — сказал он.
Мегу предвидит как минимум две проблемы с аварийным выключателем: во-первых, немногие администраторы смогут легко оценить его влияние на сервисы своей организации. По его словам, аварийный выключатель легко сработает для уязвимости Copy Fail, «но как стратегия для всех потенциальных рисков? Каковы будут последствия отключения функций ядра для изменений? Это потребует тестирования и проверки, а полная проверка вне производственной среды все равно займет время и усилия».
Во-вторых, отметил он, простое срабатывание аварийного выключателя и надежда на лучшее — не лучшая стратегия для корпоративных поддерживаемых приложений.
Мегу добавил, что уязвимость Copy Fail нетипична для всех проблем, с которыми сталкиваются специалисты по Linux. Короче говоря, по его мнению, аварийный выключатель «похож на пластырь, который подходит только для определенных порезов».
Роберт Эндерл из Enderle Group заявил, что предложение об аварийном выключателе — это классический инструмент типа «разбить стекло в случае чрезвычайной ситуации». Он отметил: «Для корпоративных администраторов это крайне прагматичный ответ на задержку между раскрытием информации о нулевом дне и развертыванием патча. В средах с высокой доступностью, где перезагрузка парка машин — это кошмар, возможность отключить конкретную, несущественную функцию (например, малоизвестный сетевой протокол), которая в данный момент эксплуатируется, является огромным преимуществом. Это, по сути, обмен нишевой функцией на немедленную целостность системы без простоя, связанного с полным циклом установки патчей».
Однако он добавил, что эта возможность может быть палкой о двух концах. «Хотя это не создает новую точку входа — для активации по-прежнему требуется доступ root — это открывает дверь для массового самоумышленного отказа в обслуживании. Нет никакой страховки; если администратор по ошибке отключит критически важную функцию управления памятью, система будет уничтожена».
Он указал, что это также может стать костылем, позволяющим организациям откладывать фактическое исправление. «Это острый инструмент, который должен находиться в руках опытных групп по безопасности, но для среднего системного администратора он, вероятно, слишком “ядерный” для комфортного использования», — сказал он. «Учитывая, как сегодня укомплектованы ИТ-отделы, это, вероятно, слишком опасно для большинства, чтобы рассматривать возможность использования».
Но представитель дистрибьютора Linux компании Red Hat заявил, что компания считает, что это сработает.
«Мы поддерживаем включение возможностей аварийного выключателя в ядро, особенно с учетом роста темпов и серьезности эксплойтов благодаря сканированию на основе LLM», — сообщил CSO Майк Макграт, вице-президент по основным платформам в Red Hat. «Патчи абсолютно критичны для устранения CVE, но они также часто нарушают работу. Большинство организаций, работающих в больших масштабах, должны сопоставлять защиту на основе патчей с влиянием перезапусков и обновлений на производство. Это означает, что неразрушающие меры смягчения последствий, которые Red Hat часто предоставляет всеми доступными средствами, жизненно важны для защиты “в моменте” до тех пор, пока не будет проверен и развернут постоянный патч».
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Howard Solomon
