| · | 20.05.2026 | Релиз Firefox 151 (9) |
|
Состоялся релиз web-браузера Firefox 151 и сформированы обновления прошлых веток с длительным сроком поддержки - 140.11.0 и 115.36.0. На стадию бета-тестирования в ближайшее время будет переведена ветка Firefox 152, релиз которой намечен на 16 июня.
Основные новшества в Firefox 151 (1, 2, 3, 4):
Кроме новшеств и исправления ошибок в Firefox 151 устранено 154 уязвимости (65 собрано под CVE-2026-8973, 54 под CVE-2026-8974 и 7 под CVE-2026-8975). 146 уязвимостей вызваны проблемами работы с памятью, такими как переполнения буферов и обращение к уже освобождённым областям памяти. Потенциально данные проблемы способны привести к выполнению кода злоумышленника при открытии специально оформленных страниц. В ночных сборках Firefox началось тестирование переделанного интерфейса конфигуратора, в котором расширены средства для поиска настроек, улучшена навигация, обновлены метки и описание настроек.
| ||
|
Обсуждение (9) |
Тип: Программы |
| ||
| · | 20.05.2026 | Атакующие получили доступ к внутренним репозиториям GitHub и OpenAI (44 +8) |
|
Сервис GitHub предупредил о выявлении неавторизированного доступа к своим внутренним репозиториям. Причиной стала компрометация рабочей станции одного из сотрудников, установившего новую версию одного из расширений к редактору кода VS Code, в которую был интегрирован вредоносный код. Подробности обещают опубликовать после завершения разбирательства. По предварительным данным информация пользователей, хранимая вне внутренних репозиториев компании GitHub, не пострадала. Атака ограничилась утечкой информации из примерно 3800 внутренних репозиториев, принадлежащих GitHub.
Какое именно дополнение к VS Code было установлено не уточняется. Из недавних атак на пользователей VS Code можно отметить вчерашний инцидент с дополнением Nx Console, насчитывающим 2.2 млн установок. Злоумышленникам удалось перехватить информацию для подключения к учётной записи на GitHub одного из разработчиков Nx Console и опубликовать новый релиз 18.95.0, содержащий вредоносный код для кражи конфиденциальных данных, таких как пароли и токены доступа к GitHub, npm, AWS, HashiCorp Vault, Kubernetes и 1Password. Вредоносный выпуск был размещён в каталоге Visual Studio Marketplace 19 мая в 15:30 и удалён в 15:48 (MSK). Дополнительно стоит упомянуть компрометацию 11 мая двух рабочих станций сотрудников компании OpenAI, установивших вредоносные обновления NPM-пакетов TanStack, содержащие саморастространяющийся червь. Вредоносные версии были опубликованы в результате атаки на процесс формирования релизов на базе GitHub Actions в проекте TanStack. В результате активности червя на сервер злоумышленников были отправлены учётные данные и ключи доступа, находящиеся на скомпрометированных компьютерах сотрудников OpenAI. Отмечается, что у скомпрометированных систем был ограниченный доступ к некоторым внутренним репозиториям OpenAI, в которых среди прочего хранились сертификаты для формирования цифровых подписей к продуктам для платформ Windows, macOS, iOS и Android. После выявления проблемы в OpenAI был инициирован процесс замены сертификатов, используемых для заверения цифровой подписью ChatGPT Desktop, Codex App, Codex CLI и Atlas. Интересно, что это не первый подобный инцидент в OpenAI - системы сотрудников данной компании также были поражены вредоносным ПО в апреле после установки вредоносного релиза NPM-пакета Axios, который атакующим удалось опубликовать в результате перехвата учётных данных главного сопровождающего. После данного инцидента на компьютерах разработчиков была реализована защита от установки вредоносных зависимостей, но на системы сотрудников, впоследствии скомпрометированных через TanStack, её не установили.
| ||
|
Обсуждение (44 +8) |
Тип: Проблемы безопасности |
| ||
| · | 19.05.2026 | Компания Canonical опубликовала монолитный дистрибутив Ubuntu Core 26 (29 –5) |
|
Компания Canonical представила релиз Ubuntu Core 26, компактного варианта дистрибутива Ubuntu, адаптированного для применения на устройствах интернета вещей (IoT), в контейнерах, потребительском и промышленном оборудовании. Ubuntu Core поставляется в форме неделимого монолитного образа базовой системы, в котором не применяется разбивка на отдельные deb-пакеты. Образы Ubuntu Core 26, состав которых синхронизирован с пакетной базой Ubuntu 26.04, подготовлены для систем x86_64 и ARM64. Время сопровождения выпуска составит 15 лет.
Ubuntu Core служит основой для запуска дополнительных компонентов и приложений, которые оформляются в виде самодостаточных надстроек в формате snap. Компоненты Ubuntu Core, включая базовую систему, ядро Linux и системные надстройки, также поставляются в формате snap и управляются инструментарием snapd. Технология Snap даёт возможность сформировать образ системы как единое целое, без разбиения на отдельные пакеты. Вместо поэтапного обновления на уровне отдельных deb-пакетов в Ubuntu Core применяется механизм атомарного обновления snap-пакетов и базовой системы, по аналогии с Fedora Atomic, ChromeOS, Endless и openSUSE Leap Micro. При обновлении базового окружения и snap-пакетов имеется возможность отката состояния до прошлой версии, в случае проблем, выявленных после обновления. Для обеспечения безопасности каждый компонент системы верифицируется по цифровой подписи, что позволяет защитить дистрибутив от внесения скрытых модификаций или установки непроверенных snap-пакетов. Поставляемые в формате Snap компоненты изолируются при помощи AppArmor и Seccomp, что создаёт дополнительный рубеж для защиты системы в случае компрометации отдельных приложений. Базовая система включает только минимальный набор необходимых приложений, что не только позволило уменьшить размер системного окружения, но и положительно сказалось на безопасности за счёт уменьшения возможных векторов для атак. Базовая файловая система монтируется в режиме только для чтения. Имеется возможность использования шифрования данных на накопителе с использованием TPM. Обновления выпускаются регулярно, доставляются в режиме ОТА (over-the-air) и синхронизированы с составом Ubuntu 26.04. Для минимизации трафика обновления поставляются в сжатом виде и включают только изменения, относительно прошлого обновления (delta-обновления). Автоматизация установки обновлений решает проблемы с поддержанием безопасности системы при использовании на встраиваемых устройствах. Благодаря логическому отделению базовой системы от приложений, поддержанием кодовой базы Ubuntu Core в актуальном виде занимаются разработчики Ubuntu, а об актуальности дополнительных приложений заботятся разработчики приложений. Подобный подход позволяет снизить затраты на сопровождение продуктов, программное окружение которых построено на основе Ubuntu Core, так как их производителям не требуется заниматься выпуском и доставкой системных обновлений и достаточно сосредоточить внимание только на своих специфичных компонентах.
| ||
|
Обсуждение (29 –5) |
Тип: Программы |
| ||
| · | 19.05.2026 | Microsoft развивает дистрибутив общего назначения Azure Linux 4 на базе Fedora Linux (28 +2) |
|
Компания Microsoft опубликовала наработки, связанные с дистрибутивом Azure Linux 4, который по сравнению с веткой 3.0 кардинально переработан и переведён с собственной пакетной базы на использование пакетов из дистрибутива Fedora 43. Если ранее Azure Linux позиционировался как платформа для Linux-окружений, используемых в облачной инфраструктуре, edge-системах и различных сервисах Microsoft, то теперь Azure Linux преподносится как защищённая и надёжная операционная система общего назначения, оптимизированная для облака Azure, которую можно использовать в виртуальных машинах, контейнерах, окружении WSL (Windows Subsystem Linux) и в качестве основной ОС на компьютерах.
Ветка Azure Linux 4 отмечена как находящаяся в процессе разработки. Для рабочих внедрений рекомендуется использовать ветку Azure Linux 3. Готовые сборки пока не предоставляются, но имеется инструкция по сборке. Специфичные для дистрибутива изменения поставляются под лицензией MIT. При формировании дистрибутива вместо создания форка Fedora в Azure Linux 4 применён декларативный подход, позволяющий пересобирать RPM-пакеты с необходимыми изменениями и настройками из штатных репозиториев Fedora, используя конфигурационные файлы в формате TOML. Дополнительная функциональность определяется в форме оверлеев, позволяющих генерировать специфичные для Azure Linux spec-файлы пакетов на основе штатных SRPM-пакетов из Fedora Linux. Оверлеи определяют изменения, вносимые поверх пакетов Fedora, такие как дополнительные конструкции в spec-файлах, патчи и параметры сборки. Пакетной единицей в Azure Linux 4 являются "компоненты" (исходный пакет), которые по большей части импортируются из Fedora через dist-git и могут формировать один или несколько RPM-пакетов. Все компоненты собираются из исходного кода, бинарные пакеты из Fedora не переносятся. Для генерации результирующих RPM-пакетов на основе оверлеев применяется инструментарий azldev, написанный на языке Go и поставляемый под лицензией MIT. Из особенностей Azure Linux 4 отмечается поставка ядра Linux с дополнительными оптимизациями, защита от атак через зависимости (supply chain), предсказуемый цикл поддержки и выпуска обновлений, встроенные возможности для интеграции с облаком Azure, изменения для усиления безопасности. Система сборки Azure Linux позволяет генерировать как установочные окружения с RPM-пакетами, так и монолитные системные образы, формируемые при помощи инструментария rpm-ostree и обновляемые атомарно без разбивки на отдельные пакеты. Поддерживается две модели доставки обновлений: через обновление отдельных пакетов и через перестроение и обновление всего системного образа. Из применяемых в Azure Linux мер по повышению безопасности:
| ||
|
Обсуждение (28 +2) |
Тип: Программы |
Интересно
| ||
| · | 19.05.2026 | PinTheft - шестая уязвимость класса Copy Fail, предоставляющая права root в Linux (70 +17) |
|
Раскрыта информация о шестой уязвимости (1, 2-3, 4, 5), позволяющей непривилегированному локальному пользователю получить права root, перезаписав данные в страничном кэше. Уязвимость получила кодовое имя PinTheft. Доступен прототип эксплоита. CVE-идентификатор ещё не присвоен. Исправление пока доступно только в виде патча, который опубликован 5 мая и 11 мая был принят в ветку netdev, но не включён в корректирующие выпуски ядра.
Уязвимость присутствует в реализации сетевого протокола RDS (Reliable Datagram Sockets), предназначенного для высокоскоростного обмена сообщениями между узлами в кластере, с минимальной задержкой и гарантированной доставкой. Атака возможна на системы с включённой подсистемой io_uring (io_uring_disabled=0) и ядром, собранным с опциями CONFIG_RDS, CONFIG_RDS_TCP и CONFIG_IO_URING. Для работы эксплоита в системе должен быть доступный на чтение исполняемый файл с флагом SUID-root. Для автоматической загрузки модуля ядра rds_tcp эксплоит запрашивает отправку данных через RDS с использованием транспорта SO_RDS_TRANSPORT=2. Отмечается, что среди протестированных дистрибутивов Linux в конфигурации по умолчанию модуль ядра rds предоставляется только в Arch Linux. Для блокирования уязвимости обходным путём можно заблокировать автозагрузку модулей ядра rds и rds_tcp: rmmod rds_tcp rds printf 'install rds /bin/false\ninstall rds_tcp /bin/false\n' > /etc/modprobe.d/pintheft.conf Уязвимость вызвана ошибкой в реализации механизма zerocopy в функции rds_message_zcopy_from_user(), осуществляющей прямое изменение данных в страничном кэше для исключения лишней буферизации. В случае сбоя не производилась очистка поля rm->data.op_nents, из-за чего выполнялось двойное освобождение буфера (double-free). Появление некорректного значения в счётчике ссылок удалось эксплуатировать для перезаписи данных в страничном кэше, благодаря манипуляции с указателем на фиксированный буфер io_uring. В остальном механизм эксплуатации типичен для всех уязвимостей данного класса - атакующий добивается оседания файла программы с флагом suid root в страничном кэше, после чего подставляет в ELF-заголовок код для запуска /usr/bin/sh. После данной манипуляции запуск программы приводит к загрузке в память не оригинального исполняемого файла с накопителя, а изменённой копии из страничного кэша. В отличие от прошлых эксплоитов, новый вариант адаптирован не только для атаки на утилиту "su", но и может применяться при наличии в системе таких suid-программ, как mount, passwd, chsh, newgrp, umount и pkexec.
| ||
|
Обсуждение (70 +17) |
Тип: Проблемы безопасности |
| ||
| · | 19.05.2026 | IncidentRelay - открытая система для организации дежурств и маршрутизации оповещений (11 +10) |
|
Опубликован проект IncidentRelay, развивающий открытую систему для организации дежурств, маршрутизации оповещений и сопровождения инцидентов, запускаемую на собственном сервере (self-hosted). Проект ориентирован на SRE, DevOps и инфраструктурные команды, которым требуется локально разворачиваемая альтернатива SaaS-сервисам для управления дежурством (on-call management), применения политик эскалации и реагирования на инциденты. Код проекта написан на Python и распространяется под лицензией MIT.
IncidentRelay принимает события из систем мониторинга, сопоставляет их с правилами маршрутизации и доставляет уведомления ответственным дежурным или командам. В системе реализованы расписания дежурств, ротации, переопределения смен, подтверждение получения инцидента, перевод инцидента в resolved, напоминания, эскалации и silences для подавления известных или плановых срабатываний. Поддерживается приём событий из Prometheus Alertmanager, Zabbix и произвольных webhook-ов. Для отправки уведомлений предусмотрены каналы Mattermost, Telegram, email, webhook и голосовые провайдеры. В Mattermost и Telegram уведомления могут содержать действия для подтверждения и решения проблемы, что позволяет обрабатывать инцидент без перехода в отдельный интерфейс. В IncidentRelay предусмотрена модель разделения доступа по группам и командам. Это позволяет разграничить видимость расписаний, маршрутов, каналов уведомлений и алертов между различными командами. Для автоматизации доступен HTTP API, а для интеграций используются bearer-токены и route-токены. Проект может применяться как промежуточный слой между системами мониторинга и каналами уведомлений: Alertmanager или Zabbix отправляет событие в IncidentRelay, после чего система определяет команду, текущего дежурного, применяет правила маршрутизации и отправляет уведомление в нужный канал. Для неподтверждённых инцидентов могут выполняться повторные напоминания и эскалация на следующего участника ротации. ![]() ![]()
| ||
| · | 18.05.2026 | DirtyDecrypt - очередная уязвимость класса Copy Fail, предоставляющая права root в Linux (79 +20) |
|
В ядре Linux выявлена уязвимость, по аналогии с уязвимостями Copy Fail, Dirty Frag и Fragnesia позволяющая непривилегированному пользователю получить права root, перезаписав данные в страничном кэше. Уязвимости присвоено кодовое имя DirtyDecrypt (проблема также упоминается под именем DirtyCBC). Доступен прототип эксплоита.
CVE-идентификатор в примечании к эксплоиту не упоминается, указано лишь, что исследователи выявили проблему 9 мая, после чего сообщили об этом разработчикам ядра, которые ответили, что их находка дублирует другой отчёт об уже исправленной уязвимости. Так как патч с исправлением уже включён в ядро исследователи решили опубликовать разработанный ими эксплоит. Судя по описанию внутри эксплоита, в нём используется уязвимость CVE-2026-31635, исправление для которой было принято в ядро в апреле и вошло в состав ветки 7.0.0 и сформированного 18 апреля выпуска 6.18.23. Проблема проявляется начиная с ядра 6.16. Как и в случае с серией уязвимостей Dirty Frag новая уязвимость присутствует в драйвере RxRPC, реализующем семейство сокетов AF_RXRPC и одноимённый RPC-протокол, работающий поверх UDP. Проблема вызвана ошибкой при проверке размера данных в функции rxgk_verify_response() - вместо проверки "if (auth_len > len)" в коде было указано "if (auth_len < len)", что приводило к передаче в функцию rxgk_decrypt_skb() данных с размером, больше допустимого. При выполнении функции rxgk_decrypt_skb() расшифровка данных осуществлялась с подстановкой изменений напрямую в страничный кэш для исключения лишней буферизации. Из-за неверной проверки размера возникала возможность перезаписи данных в страничном кэше по выбранному смещению. Эксплуатация уязвимости сводится к чтению файла программы с флагом suid root (для его оседании в страничном кэше) и замене в страничном кэше части кода программы кодом для запуска /usr/bin/sh. Последующий запуск программы приведёт к тому, что в память будет загружен не оригинальный исполняемый файл с накопителя, а изменённая копия из страничного кэша. В качестве suid-программ в эксплоите предусмотрена возможность использования "/usr/bin/su", "/bin/su", "/usr/bin/mount", "/usr/bin/passwd" и "/usr/bin/chsh". Для эксплуатации уязвимости при сборке ядра должна быть активна опция CONFIG_RXGK (проверить можно командой "grep CONFIG_RXGK /boot/config-$(uname -r)"), а для автозагрузки доступен модуль ядра rxrpc.ko (в некоторых системах он не собирается). Работа экплоита проверена в Fedora, и предполагается, что уязвимость также проявляется в ядрах из Arch Linux и openSUSE Tumbleweed. Статус устранения уязвимостей в дистрибутивах можно оценить на данных страницах: Debian, Ubuntu, SUSE/openSUSE, RHEL, Arch, Fedora. В качестве обходного пути защиты можно заблокировать загрузку модуля ядра rxrpc: sh -c "printf 'install rxrpc /bin/false\n' > /etc/modprobe.d/dirtydecrypt.conf; rmmod rxrpc 2>/dev/null; true" Дополнительно можно отметить публикацию в списке рассылки разработчиков ядра Linux патчей, полностью отключающих в crypto API (AF_ALG) оптимизации, использующие прямое обращение к страничному кэшу при расшифровке с использованием алгоритмов "skcipher" и "aead". Оптимизации исключают лишнюю буферизацию данных, но создают риски возникновения серьёзных уязвимостей. Предполагается, что их отключение приведёт лишь к незначительному снижению производительности из-за появления дополнительной операции копирования в отдельный буфер. Патчи приняты сопровождающим подсистему crypto API и включены в ветку "cryptodev", в которой развиваются возможности для передачи в основной состав будущих выпусков ядра Linux.
| ||
|
Обсуждение (79 +20) |
Тип: Проблемы безопасности |
| ||
| · | 18.05.2026 | Выпуск Phosh 0.55.0, GNOME-окружения для смартфонов (26 +8) |
Опубликован релиз Phosh 0.55, экранной оболочки для мобильных устройств, основанной на технологиях GNOME и библиотеке GTK. Окружение изначально развивалось компанией Purism в качестве аналога GNOME Shell для смартфона Librem 5, но затем вошло в число неофициальных проектов GNOME и используется в postmarketOS, Mobian, ALT Mobile, Droidian, некоторых прошивках для устройств Pine64 и редакции Fedora для смартфонов. Phosh использует композитный сервер Phoc, работающий поверх Wayland, а также собственную экранную клавиатуру. Наработки проекта распространяются под лицензией GPLv3+.
![]() Среди изменений:
| ||
|
Обсуждение (26 +8) |
Тип: Программы |
| ||
| · | 18.05.2026 | Линус Торвальдс раскритиковал приватный разбор уязвимостей, выявленных при помощи AI (105 +51) |
|
В анонсе очередного предварительного выпуска ядра 7.1-rc4 Линус Торвальдс призвал исследователей безопасности, использующих AI, не отправлять отчёты о найденных уязвимостях в приватный список рассылки "security@kernel.org" и следовать принятым на днях правилам и модели угроз при отправке информации об уязвимостях. Отмечается, что использование типовых AI-инструментов приводит к выявлению одних и тех же уязвимостей и отправке большого числа дублирующихся отчётов, разбор которых создаёт огромную дополнительную нагрузку на сопровождающих и мешает нормальной работе через список рассылки.
Список рассылки "security@kernel.org" является закрытым и сторонние исследователи имеют возможность только отправить отчёт, но не могут просматривать отчёты, отправленные другими участниками, и их обсуждение разработчиками ядра. Приватный разбор уязвимостей, выявленных при помощи AI-инструментов, признан пустой тратой времени как для сопровождающих, тратящих ресурсы на отсеивание дубликатов, так и для разработчиков, впустую анализирующих проблемы, о которых уже сообщил кто-то другой. В связи с этим предписано сообщать об уязвимостях, выявленных при помощи AI, только через публичные списки рассылки, за исключением особо критических проблем. Исследователям безопасности рекомендуется не заниматься бездумной переотправкой того, что выдаёт AI-ассистент, а проанализировать проблему, убедиться в её существовании, изучить документацию по отправке отчётов об ошибках, подготовить патч и тщательно проверить, не исправлена ли уже проблема в актуальной кодовой базе ядра, чтобы сопровождающие не отвлекались на написание ответов о том, что проблема уже исправлена неделю или месяц назад. По мнению Линуса AI-инструменты великолепны, но только когда действительно помогают, а не создают лишнюю головную боль и бессмысленную имитацию работы. Использование AI-инструментов при разработке ядра допустимо, но так, чтобы это приводило к результату и делало работу приятнее.
| ||
|
Обсуждение (105 +51) |
Тип: К сведению |
| ||
| · | 17.05.2026 | ModuleJail для блокировки неиспользуемых модулей ядра Linux (68 +18) ↻ |
|
Джаспер Нюйенс (Jasper Nuyens), основатель организации Linux Belgium, создавший надстройку для использования Linux в информационной системе автомобилей Tesla, предложил простой способ снизить поверхность атаки на ядро Linux для снижения вероятности компрометации на фоне всплеска выявления опасных уязвимостей при помощи AI. Так как многие уязвимости находят в специфичных модулях ядра, доступных для автозагрузки, но обычно не применяемых большинством пользователей, Джаспер предложил по умолчанию блокировать неиспользуемые в текущей системе или в общем виде редко используемые модули.
В ядре доступно несколько тысяч модулей, но в большинстве систем используется только несколько сотен, а остальные остаются доступны для загрузки и потенциально могут содержать уязвимости. Идея реализована через скрипт ModuleJail, который определяет список используемых в текущей системе модулей (через /proc/modules) и автоматически помещает неиспользуемые модули в чёрный список. Скрипт написан на shell, использует распространённые системные утилиты (достаточно busybox) и распространяется под лицензией GPLv3. Скрипт поддерживает выполнение в Debian, Ubuntu, RHEL, Fedora, SUSE, AlmaLinux, Rocky Linux, Alpine и Arch Linux, и в результате своей работы генерирует файл /etc/modprobe.d/modulejail-blacklist.conf, который штатно используется в системе для отключения автозагрузки модулей ядра. Подобный подход позволяет превентивно защитить свою систему, не прибегая к загрузке специализированных модулей ядра или выполнения дополнительных фоновых процессов для мониторинга за системой. При необходимости пользователю предоставлена возможность добавления в белый список модулей, которые в данным момент не загружены, но потенциально могут использоваться в работе. Также доступны для включения профили, допускающих использование наиболее необходимых модулей для типовых применений системы. Предложены профили "minimal" (только самые важные модули и основные ФС), "conservative" (+ типовые драйверы для серверов и виртуальных машин) и desktop (+ драйверы для WiFi, Bluetooth, звука и видео). Отдельно предлагается скрипт cve-watch.sh, осуществляющий мониториг списка рассылки linux-cve-announce и REST API nvd.nist.gov на предмет обнаружения уязвимостей в незаблокированных модулях ядра. Как правило CVE-идентификаторы уязвимостей раскрываются раньше устранения проблемы в дистрибутивах, что позволяет на ранних стадиях блокировать проблемы обходным путём. Дополнение 1: Опубликован скрипт похожего назначения, блокирующий автозагрузку модулей ядра спустя 3 минуты после загрузки системы, за исключением модулей из белого списка /etc/restricted-module-load.whitelist. Для инструментария kmod, используемого для управления загрузкой модулей ядра, подготовлен патч, добавляющий режим работы на основе белого списка, по умолчанию разрешающего загрузку только избранных модулей. Дополнение 2: В своё время проект grsecurity реализовал небольшой патч, позволяющий разрешить автоматическую загрузку модулей ядра только приложениям, запущенным с правами root.
| ||
|
Обсуждение (68 +18) ↻ |
Тип: Программы |
| ||
| · | 16.05.2026 | На соревновании Pwn2Own в Берлине продемонстрированы взломы RHEL, Windows 11 и AI-агентов (147 +18) |
|
Подведены итоги трёх дней соревнований Pwn2Own Berlin 2026, на которых были продемонстрированы успешные атаки с использованием 47 ранее неизвестных уязвимостей (0-day) в операционных системах, браузерах, AI-системах и платформах виртуализации. При проведении атак использовались самые свежие программы и операционные системы со всеми доступными обновлениями и в конфигурации по умолчанию.
Суммарный размер выплаченных вознаграждений составил более $1.2 миллиона долларов США ($1 298 250). Наиболее успешная команда DEVCORE сумела заработать на соревнованиях 505 тысяч долларов США. Обладатели второго места (STARLabs SG) получили 242 тысячи долларов, а третьего (Out Of Bounds) - 95 тысяч долларов. ![]() Осуществлённые атаки:
Кроме вышеотмеченных успешных атак, 7 попыток эксплуатации уязвимостей завершились неудачей, во всех случаях из-за того, что команды не успели уложиться в отведённое для атаки ограниченное время. Неудачными оказались попытки взлома VMware ESXi, Apple Safari, Microsoft SharePoint, Red Hat Enterprise Linux, Firefox, OpenAI Codex, Oracle Autonomous AI Database, NV Container Toolkit. В соответствии с условиями конкурса детальная информация о всех продемонстрированных 0-day уязвимостях будет опубликована только через 90 дней, которые даются на подготовку производителями обновлений с устранением уязвимостей.
| ||
|
Обсуждение (147 +18) |
Тип: К сведению |
| ||
| · | 16.05.2026 | Модель угроз и особенности оценки уязвимостей в ядре Linux (32 +26) |
|
Линус Торвальдс принял в состав ядра документ, регламентирующий процесс обработки ошибок, связанных с безопасностью, определяющий модель угроз, поясняющий, какие ошибки в ядре трактуются как уязвимости, и разбирающий действия с ошибками, выявленными при помощи AI. Документ подготовлен Вилли Тарро (Willy Tarreau), автором HAProxy и давним разработчиком ядра Linux, отвечавшим за сопровождение нескольких стабильных веток ядра. В качестве основы использованы договорённости, достигнутые в ходе обсуждения недавно выявленных критических уязвимостей в ядре (1, 2, 3, 4), раскрытых до публикации исправлений и для которых, благодаря AI, удалось сразу создать рабочие эксплоиты.
Основную массу связанных с безопасностью ошибок предписывается обрабатывать публично, чтобы привлечь максимально широкую аудиторию и найти оптимальное решение. В отдельный приватный список рассылки предлагается отправлять только экстренные сообщения об уязвимостях, легко эксплуатируемых, представляющих угрозу для многих пользователей и позволяющих получить расширенные привилегии или возможности. Уязвимости, выявленные при помощи AI-ассистентов, всегда предлагается обсуждать публично, так как подобные проблемы часто обнаруживаются одновременно несколькими исследователями. При этом не следует раскрывать в отчёте эксплоит - достаточно упомянуть, что он доступен, и передать его в частном порядке в ответ на запрос сопровождающего. Отдельно описываются правила передачи отчётов, созданных при помощи AI-ассистентов. Подобных отчётов присылают очень много и благодаря им время от времени удаётся выявлять ошибки в плохо отрецензированных частях кода, но сопровождающие часто их игнорируют из-за низкого качества и неточностей. Основные требования к отчётам, созданными при участии AI:
По статистике сопровождающих, большинство отчётов об ошибках, присылаемых под видом устранения уязвимостей, таковыми не являются, и должны обрабатываться в общем порядке как обычные ошибки. Для разделения уязвимостей и обычных ошибок описана модель угроз ядра Linux. Среди возможностей и гарантий, нарушение которых может рассматриваться как уязвимость:
Возможности, которые не рассматриваются как уязвимости:
| ||
|
Обсуждение (32 +26) |
Тип: К сведению |
| ||
| · | 16.05.2026 | Релиз Erlang/OTP 29 (54 +12) |
|
Состоялся релиз функционального языка программирования Erlang 29, нацеленного на разработку распределённых отказоустойчивых приложений, обеспечивающих параллельную обработку запросов в режиме реального времени. Язык получил распространение в таких областях, как телекоммуникации, банковские системы, электронная коммерция, компьютерная телефония и организация мгновенного обмена сообщениями. Одновременно выпущен релиз OTP 29 (Open Telecom Platform) - сопутствующего набора библиотек и компонентов для разработки распределённых систем на языке Erlang.
Основные новшества:
| ||
|
Обсуждение (54 +12) |
Тип: Программы |
| ||
| · | 15.05.2026 | QEMUtiny - уязвимости в QEMU, позволяющие получить доступ к хост-окружению из гостевой системы (77 +13) |
|
Исследователи, которые на днях выявили уязвимость Fragnesia в ядре Linux, опубликовали информацию об уязвимостях в QEMU, позволяющих из гостевой системы получить root-доступ к хост-окружению. Проблеме присвоено кодовое имя QEMUtiny, но CVE-идентификатор пока не назначен. Подготовлен эксплоит, в котором задействованы две уязвимости в коде эмуляции устройства CXL (Compute Express Link).
Обе уязвимости присутствуют в коде cxl-mailbox-utils.c. Первая уязвимость проявляется начиная с выпуска QEMU 7.1.0 и приводит к чтению памяти из области вне выделенного буфера из-за того, что функция cmd_logs_get_log() ошибочно трактует запрошенное смещение CEL-лога как индекс в массиве, в то время как оно задаётся в байтах. Вторая уязвимость проявляется начиная с QEMU 11.0.0 и приводит к переполнению буфера в функции cmd_features_set_feature() из-за обработки смещения на структуры при записи атрибутов без проверки, что вычисленное значение "offset + bytes_to_copy" укладывается в размер выбранной структуры. Фактически атака возможна только на последнюю ветку QEMU 11.0.0. Об исправлении пока ничего не сообщается, указано только, что перед раскрытием уязвимости, информация о ней была передана разработчикам QEMU, которые ответили, что поддержка устройства CXL в QEMU реализована не для использования при виртуализации. Эксплоит проверен с кодовой базой QEMU от 11 мая с последним коммитом 5e61afe. Работа эксплоита завязана на раскладку структур в памяти каждой конкретной сборки QEMU и системной libc, но по мнению исследователей, воспользовавшись для сканирования памяти уязвимостью, приводящей к чтению из области вне буфера, можно создать универсальный эксплоит, работающий с разными версиями QEMU.
| ||
|
Обсуждение (77 +13) |
Тип: Проблемы безопасности |
| ||
| · | 15.05.2026 | Пересмотр решения о создании редакции Fedora AI Developer Desktop (66 +9) |
|
Управляющий совет проекта Fedora (Fedora Council) отозвал ранее принятое решение о создании Fedora AI Developer Desktop - официальной редакции дистрибутива для разработчиков, использующих AI-инструменты. Изначально все 6 членов управляющего совета проголосовали за создание проекта, но после ознакомления с критикой, высказанной в ходе обсуждения в сообществе, через несколько дней два участника изменили свои голоса и высказались против. Так как единогласия не достигнуто, утверждение решения отложено. Вопрос планируют решить до проведения конференции Flock 2026, которая пройдёт с 14 по 16 июня.
Недовольство связано с намерением использовать в составе Fedora AI Developer Desktop сторонние модули ядра и проприетарные компоненты для поддержки технологии NVIDIA CUDA. Поставка сторонних модулей нарушает сложившийся в проекте консенсус в отношении политики поставки сторонних модулей ядра, а поставка CUDA идёт в разрез с идеологией проекта, не приветствующей продвижение проприетарного ПО и привязку решений к одному производителю. Кроме того, в новой редакции предлагалось поставлять LTS-ветки ядра, но не ясно кто их будет поддерживать отдельно от штатных постоянно обновляемых пакетов с ядром, сопровождаемых в Fedora. По мнению изменившего свой голос члена управляющего совета, изменение стратегии в отношении поставки модулей для ядра в Fedora требует дополнительного согласования и получения экспертных мнений от инженеров и юристов. Предполагается, что проблема может быть урегулирована через переход к поставке штатного драйвера Nova вместо сторонних отрытых модулей от компании NVIDIA, доведение которого до готовности ожидается ближе к концу года. Изначально предполагалось, что участники из сообщества обратятся к представителям управляющего совета в случае опасений по тем или иным предстоящим решениям, но на деле совет не был уведомлен о возможных проблемах и голосовал на основе информации, предоставленной автором инициативы. Для того чтобы не допускать в будущем решений совета, идущих в разрез с мнением сообщества, Джеф Спалета (Jef Spaleta), лидер проекта Fedora, предложил до начала голосования публиковать позиции совета, по которым достигнут консенсус, чтобы сообщество могло успеть отреагировать и попытаться переубедить участников. Также упоминается вариант введения предварительного голосования на этапе обсуждения вопросов, вынесенных на рассмотрение совета, с публикацией результатов вне протоколов заседаний для ознакомления сообщества с мнением совета до проведения окончательного голосования. Проект Fedora AI Developer Desktop нацелен на создание дополнительных атомарно обновляемых дектоп-редакций Fedora Linux для разработчиков, использующих и разрабатывающих AI-технологии. В качестве основы планировалось использовать наработки дистрибутивов Silverblue (GNOME) и Kinoite (KDE), дополненные модулями ядра, инструментариями, платформами и библиотеками для развёртывания AI-моделей на локальной системе, а также разработки приложений, использующих AI. Для тестирования доступен прототип сборки Fedora AI Developer Desktop на базе Fedora Silverblue. Конечной целью называется желание предоставить решение для использования AI из коробки, не требующее ручной настройки и установки дополнительного ПО. Для корректной работы многих AI-фреймворков обычно требуется ручная настройка и согласование версий ядра, драйверов NVIDIA, инструментария CUDA и runtime для запуска контейнеров. Fedora AI Developer Desktop предоставит уже протестированное рабочее окружение, позволяющее сразу запускать готовые контейнеры с преднастроенными AI-платформами и использовать средства ускорения выполнения AI-моделей при помощи GPU. Все AI-инструменты и платформы по умолчанию будут поставляться без отправки телеметрии и с отключённым обращением к облачным сервисам. Для задействования ускорения на GPU NVIDIA в состав включены открытые компанией NVIDIA модули ядра, используемые в проприетарных драйверах NVIDIA (в будущем модули ядра NVIDIA планируют заменить на драйвер Nova). Поверх открытых модулей предусмотрена возможность установки CUDA Runtime или CUDA Toolkit. Помимо GPU NVIDIA в планах упомянута возможность работы на системах с GPU ARM, AMD и Intel. Из входящих в базовую поставку компонентов, отмечены преднастроенные AI-агент Goose и графический интерфейс для создания, запуска и управления контейнерами Podman Desktop.
| ||
|
Обсуждение (66 +9) |
Тип: К сведению |
| ||
| Следующая страница (раньше) >> | ||
|
Закладки на сайте Проследить за страницей |
Created 1996-2026 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |