🐧 В Linux тоже будет своё цунами — 21 июля 2026 г. в 09:31:00.981
🐧 В Linux тоже будет своё цунами В последние месяцы в бюллетенях и новостях зачастили «именные» дефекты в Linux, причём как правило в ядре. ИИ-поиск уязвимостей оказался особенно плодотворен на богатой почве open source. Для начала — сам масштаб: ▶️ кластер Dirty Frag, связанный с дефектами page cache: Copy Fail, Dirty Frag, Fragnesia, DirtyDecrypt и DirtyClone; ▶️ ошибки повреждения памяти и логические дефекты: GhostLock, Januscape (KVM escape), Bad Epoll (гонка в I/O), CIFSwitch (обход аутентификации), а также уязвимости в nf_tables и ssh-keysign. Большинство этих ошибок довольно старые. CIFSwitch восходит к коду 2007 года, GhostLock — к 2011, а семейство уязвимостей кэша — к 2017. Что изменилось в 2026 году: стоимость аудита 30 миллионов строк видавшего виды С-кода упала почти до нуля. Однако если Microsoft аккуратно упаковывает сотни внутренних находок в гигантские наборы обновлений, у Linux-мейнтейнеров нет возможности поставлять исправления таким же образом. Linux децентрализован, и пользователям приходится иметь дело с десятками дистрибутивов, кастомными ядрами и фрагментированными версиями компонентов системы. Дистрибутивы могут отставать от патчей mainline kernel на недели, а то и месяцы. А дальше встаёт вопрос внедрения этих исправлений в инфраструктуре компаний. Если большинство Windows-хостов являются рабочими станциями, и их обычно можно перезагрузить после очередного вторника патчей, то с Linux и его применением на серверах всё сложнее. Нельзя взять и просто открыть технологическое окно обслуживания, чтобы перезагрузить 10 тысяч серверов на проде. Именно из-за отставаний в выпуске и применении заплаток почти во всех бюллетенях вендоров рано или поздно вспоминают livepatching. Чтобы системно сократить риски во всём парке Linux-хостов, реальное решение — это харденинг, закрывающий целые классы атак. Например, усилителем почти многих недавних эксплойтов выступают непривилегированные user namespace. Если ограничить user namespaces, внести в список заблокированных неиспользуемые экзотические модули вроде rxrpc или esp4/esp6 и ужесточить права доступа, можно одним махом нейтрализовать целые категории уязвимостей. С технической точки зрения это чистое и эффективное решение. С организационной, конечно, есть нюансы — оно требует трёхстороннего согласования между командами: 1️⃣ ИБ отвечает за риск, но обычно не имеет прав на изменения в production. 2️⃣ ИТ/платформенная команда обладает доступом и может развернуть изменения по всему набору хостов, но не знает приложения изнутри. 3️⃣ Команда разработки знает приложения изнутри, но вряд ли имеет полный список серверов и разработанных модулей, в которых критичны вложенная виртуализация или конкретные расширения ядра. Поскольку быстро прийти к согласию между этими тремя отделами крайне трудно, харденинг вечно откладывается, и организации скатываются к изматывающей гонке «патч — поиск окна — перезагрузка — снова патч». Но с учётом растущего числа уязвимостей, дальше так продолжаться не может. Нужно параллельно автоматизировать все процессы управления уязвимостями и выделять ресурсы на систематический харденинг — это требует политической поддержки совета директоров.