Если вы в Казахстане и вам нужен сервис для безопасного хранения и управления артефактами ПО — забирайте!

Теперь наш Yandex Cloud Registry доступен и в Казахстане ⭐️

В Yandex Cloud Registry можно хранить:
🔺Docker‑образы
🔺Java-артефакты
🔺Node.js‑артефакты

Благодаря реестру Yandex Cloud Registry вы значительно упростите управление зависимостями между компонентами проекта.

Реестр — это централизованное хранилище и инструмент управления различными файлами, которые используются при разработке и развертывании приложений.

Команды, которые работают над крупными и сложными проектами, смогут хранить в каждом реестре наборы версий пакетов, связанных с определёнными ресурсами облака.

Узнать подробнее и попробовать Yandex Cloud Registry бесплатно⏩

⚡️ Закрываем свежую уязвимость в ядре Linux

Copy Fail (CVE-2026-31431) — это логическая уязвимость в подсистеме криптографического API ядра Linux, позволяющая обычному пользователю системы получить права суперпользователя (root). PoC работает на всех основных дистрибутивах Linux, выпущенных с 2017 года и до момента выхода патча, без модификаций под конкретное ядро или дистрибутив.

Атака:

🔺 не требует удалённого доступа — только непривилегированный локальный аккаунт;

🔺не требует ни race window, ни kernel-specific смещений;

🔺 использует крипто-API ядра (AF_ALG), который включён в дефолтных конфигурациях практически всех мейнстрим-дистрибутивов;

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

Вектор атаки и уровень опасности согласно CVSS v.3.1

Базовая оценка: 7,8 HIGH

Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Подробное описание атаки в блоге →

Затронутые технологии:

▶️ ядро Linux, подсистема crypto/ (модуль algif_aead);

▶️ интерфейс пользовательского пространства AF_ALG;

▶️ системный вызов splice() в связке с сокетами AF_ALG.

Уязвимыми являются ядра Linux, собранные в интервале с 2017 года (момент внедрения in-place оптимизации algif_aead) до момента включения исправляющего патча мейнлайна.

Поскольку модуль algif_aead входит в дефолтную конфигурацию ядра большинства дистрибутивов, эксплуатация возможна «из коробки».

Уязвимость напрямую не затрагивает следующие пути использования крипто-API: dm-crypt / LUKS, kTLS, IPsec/XFRM, in-kernel TLS, OpenSSL/GnuTLS/NSS в дефолтных сборках, SSH, kernel keyring crypto. Все они работают с in-kernel crypto API напрямую и не проходят через AF_ALG.

🔵Сайт уязвимости
🔵Технический разбор Xint Code (Theori)
🔵PoC и issue tracker

Рекомендации по обнаружению уязвимости:

⏩ Отключить модуль algif_aead до установки патча ядра.

Команда выполняется от имени root и применяется немедленно. Новые сокеты AF_ALG создаваться не смогут, ранее открытые — продолжат работать до закрытия.

 # echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
   # rmmod algif_aead 2>/dev/null || true

⏩ Обновить ядро до версии, содержащей патч.

Уязвимость:

🔵присутствует в ядрах с 4.14 (commit 72548b093ee3, 2017 год)

🔵 устранена в следующих релизах:

✓6.18.22 (стабильная ветка) — commit fafe0fa2995a

✓6.19.12 (стабильная ветка) — commit ce42ee423e58

✓7.0-rc7 (мейнлайн) — commit a664bf3d603d

Для контейнерных и sandbox-нагрузок целесообразно блокировать создание сокетов AF_ALG через seccomp независимо от состояния патчей.

Влияние на сервисы Yandex Cloud

Обновили конфигурации инфраструктуры Yandex Cloud для применения митигирующих мер.

🔔Пользователям сервиса Yandex Managed Service for Kubernetes® нужно самостоятельно применить митигирующую меру на узлах своих кластеров. Для этого опубликован DaemonSet, который отключает модуль algif_aead.

Применение выполняется штатной командой:

$ kubectl apply -f copy-fail-mitigation-daemonset.yaml

Актуальные версии образов в Yandex Cloud Marketplace, содержащие митигирующие меры, готовим к публикации.

📍 Если вам нужна дополнительная информация, пожалуйста, напишите на cloudtrust@yandex-team.ru.

👍 — спасибо, было полезно

Не принимаем новые OAuth‑токены, полученные через Яндекс ID — с 1 июня 2026 года.

Рассказываем, каких именно OAuth‑токенов коснется решение, почему мы его приняли и как перейти на безопасные альтернативы.

*️⃣ Старые OAuth‑токены, выданные до 1 июня 2026 года действуют до окончания своего срока.

Изменения касаются только OAuth‑токенов, выданных для доступа к Yandex Cloud по процедуре, описанной в инструкции по получению OAuth-токена.

Токены для других сервисов Яндекса, включая Яндекс 360, это не затрагивает.

Причина — использование персонального OAuth‑токена в инфраструктурных и автоматизированных сценариях несёт дополнительные риски безопасности.

📍 Почему мы считаем OAuth‑токены менее предпочтительными:

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

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

Сложности контроля. Владельцы организаций не могут прозрачно отследить использование таких токенов с помощью Audit Trails.

Риск скрытого создания. При компрометации учётной записи Яндекс ID злоумышленник может незаметно создать OAuth‑токен и использовать его для закрепления в облачной инфраструктуре.

Чем заменить OAuth‑токены и как перейти на альтернативы подробно рассказываем в блоге⏩