Раскрыты детали и опубликован эксплоит для уязвимости (CVE-2026-58882) в платформе Android, позволяющей добиться зацикленной перезагрузки через отправку специально оформленного SMS-сообщения. Для устранения зацикленной перезагрузки требуется сброс к заводским настройкам или ручные манипуляции при помощи утилиты ADB. Уязвимость получила кодовое имя «SMS of Death» и устранена в октябрьском обновлении репозитория AOSP. Производители устройств получили доступ к патчу в июле. Атака может быть совершена на любые телефоны, оснащённые Android 12-17. Обновление выпущено только для Android 14-17. Эксплуатирующее уязвимость SMS-сообщение обрабатывается как фоновое и не отображается на устройстве. Для проведения атаки не требуется выполнение пользователем каких-либо действий.

Проблема вызвана неконтролируемым приведением типа при обработке некорректного заголовка WAP Push-сообщения, отправленного через SMS. Переполнение возникает так как поле с размером заголовка приводится из беззнакового значения (uintvar) к 32-разрядному знаковому типу int без должной проверки границ. Из-за приведения 64-битного типа long в 32-битный int в Java корректное с точки зрения протокола значение 0x80000000 интерпретируется как отрицательное число -2147483648 в переменной headerLength. В дальнейшем эта переменная используется при выделении памяти через вызов «new byte[headerLength]», что в случае получения отрицательного числа приводит к генерации исключения и аварийному завершению процесса com.android.phone.

Через несколько секунд процесс перезапускается, но эффект не ограничивается кратковременным прерыванием связи. Проблемное WAP Push-сообщение из-за аварийного завершения продолжает находиться в очереди необработанных сообщений и новая попытка его обработки приводит к очередному аварийному завершению процесса com.android.phone.

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

Для удаления сообщения из очереди без сброса к заводским настройкам предлагается использовать утилиту adb:

   adb shell content query --uri content://sms/raw --projection _id:destination_port:date:deleted
   adb shell cmd appops set com.android.shell WRITE_SMS allow
   adb shell "content delete --uri content://sms/raw --where \"address='<SENDER>'\""
   adb shell cmd appops set com.android.shell WRITE_SMS default
   adb shell pm clear com.android.providers.telephony

Но это лишь даст возможность извлечь SIM-карту, загрузиться и установить обновление прошивки. Так как из-за аварийного завершения процесса «com.android.phone» оператору связи не отправляется подтверждение обработки WAP Push-сообщения, до истечения таймаута он будет предпринимать новые попытки отправки и ситуация будет повторяться. В проведённых тестах повторные отправки продолжались от суток до недели. Для устройств, производители которых прекратили публикацию обновлений прошивки, обходного пути блокирования проблемы пока нет, кроме обращения к оператору связи с просьбой блокировки передачи сообщений WAP Push на его стороне.

https://www.opennet.ru/opennews/art.shtml?num=66586

Грегори Курцер (Gregory Kurtzer), основатель дистрибутивов CentOS и Rocky Linux, представил проект Ginux, развивающий ядро операционной системы на языке Rust, нацеленное на достижение совместимости с ядром Linux. Опубликованный исследовательский прототип уже способен загрузить системное окружение дистрибутивов Alpine с BusyBox и Rocky Linux 10 с systemd в многопользовательском консольном режиме. Код проекта распространяется под лицензией Apache 2.0. Поддерживается работа на системах с архитектурой x86-64.

Прототип создан за 11 дней в рамках эксперимента по применению техники разработки HDAE (Human-Directed Agentic Engineering) для создания сложных проектов, уровня ядра Linux. При использовании метода HDAE код генерируется AI-агентом (использован Codex c моделью GPT-5.6 Sol), а человек сосредоточен на разработке архитектуры, принятии решений, координации работы, формировании плана разработки и определении критериев готовности развиваемых компонентов. AI-агенты также привлекаются для тестирования, рецензирования и диагностики проблем.

Проект не пытается копировать технологии из ядра Linux, а создаёт собственные совместимые реализации с оглядкой на них. Ginux предоставляет независимые систему управления памятью, планировщик задач, загрузочный процесс, модель процессов, файловые системы, сетевой стек, драйверы устройств и слой для совместимости с Linux ABI. Ядро Ginux загружается напрямую через UEFI без привлечения хостовой Linux-системы.

Ginux пока не претендует на замену Linux и не готов для использования в рабочих системах, но уже пригоден для проведения экспериментов и тестирования. В долгосрочной перспективе проект рассматривается как операционная система для запуска в изолированных контейнерах компонентов для AI-инфраструктуры. Имя Ginux сформировано как комбинация из слов GPT/Gregory и Linux. Основой платформой для тестирования является запускаемая при помощи гипервизора KVM виртуальная машина Q35 (Intel Q35/ICH) с OVMF (Open Virtual Machine Firmware), Intel IOMMU и virtio-устройствами.

Из 375 системных вызовов ядра Linux 6.12 полностью реализовано 82, частично - 245 и заблокировано из соображений безопасности - 48. Для выявления сбоев, которые невозможно выявить в синтетических тестах, работа ядра оценивается при запуске реальных приложений и библиотек, таких как musl, glibc, BusyBox и systemd.

Среди планов:

Обеспечение запуска компонентов пользовательского пространства Linux-дистрибутивов без использования ядра Linux. Возможность создания изолированных доменов со своими наборами процессов, адресным пространством, файловыми системами, устройствами, ресурсами и независимым жизненным циклом. Подготовка самодостаточного загрузочного образа. Предоставление минимального управляющего окружения в пространстве пользователя (userspace control plane), позволяющего управлять ядром без выполнения кода на нулевом кольце защиты. Система управления доступом, работающая на уровне именованных объектов. Поддержка изолированного запуска образов контейнеров в формате OCI.

https://www.opennet.ru/opennews/art.shtml?num=66562

Сопровождающий пакет (ebuild) Chromium в Gentoo Linux объявил о скором удалении пакета из репозитория из-за слишком больших трудозатрат на сопровождение. Упоминается, что сопровождающий не имеет возможности продолжать поддерживать пакет на должном уровне после сокращения цикла публикации релизов Chrome. Если в ближайшие дни не найдётся доброволец, готовый взять на себя сопровождение Chromium в Gentoo, то 24 октября пакет www-client/chromium перестанет быть доступен для установки.

Новые корректирующие версии Chromium последнее время появляются каждую неделю и содержат исправление сотен уязвимостей. Помимо участившихся релизов, сопровождение усложняют изменения в инструментарии upstream-проектов и конфликты, связанные, с одной стороны, со стремлением предоставить пользователям должное качество, избегая по-возможности встраивания зависимостей в пакет, и, с другой стороны, с необходимостью оперативной публикации обновлений с исправлением уязвимостей. Компиляция Chromium занимает 15-16 часов на ноутбуке и около 6 часов на мощном ПК, при том, что перед публикацией пакета требуется проверить все варианты сборки с разным USE-флагами.

Chromium использует большое число встроенных зависимостей (например, ffmpeg, harfbuzz, zstd), но особенно усложнило сопровождение добавление в зависимости Rust и Go. В случае с Rust проблемы связаны с использованием экспериментальных возможностей, совместимость с которыми может нарушаться с новых релизах, а Go с тем, что инструментарий требует доступа к сети, который запрещён для сборочных окружений правилами Gentoo. Помимо этого, отмечены сбои в системе непрерывной интеграции Google, которые временами приводят к публикации неполных архивов с кодом.

По мнению сопровождающего, для качественной поддержки пакета требуется команда как минимум из трёх человек со знаниями языков C, C++, Go, JavaScript и Rust, а также знакомых со специфичными инструментариями Google. У одного сопровождающего на поддержание Chromium уходит более 6 часов в неделю, т.е. почти целый рабочий день из своего свободного времени, и это не считая ситуаций, в которых приходится диагностировать и исправлять ошибки, а также приводить состояние сборки к соответствию требованиям Gentoo.

Последней каплей, после которой сопровождающий решил прекратить поддержание пакета, стало обесценивание его труда при обсуждении слишком медленной публикации обновлений Chromium в Gentoo (в Gentoo сейчас поставляется версия 151 при актуальном выпуске 155). Один из участников дискуссии предложил использовать готовый ebuild-сценарий из стороннего репозитория Bentoo, поддержание которого автоматизировано. Сопровождающий пояснил, что простое копирование недопустимо без аудита изменений и полного тестирования всех вариантов сборки с разными USE-флагами, иначе невозможно гарантировать работоспособность пакета у всех пользователей. На что получил, ответ, что всё это чушь (ridiculous).

В случае удаления пакета www-client/chromium, пользователи могут переключится на использование пакета www-client/google-chrome, в котором упакованы поставляемые Google бинарные сборки Chrome, или использовать сторонние сборки Chromium в формате Flatpak.

https://www.opennet.ru/opennews/art.shtml?num=66489

Перемещено hobbit из general

По дефолту почему-то timestamp не показывается, хотя это просто обязательный атрибут в логах, без которого причинно-следственные связи трудно установить. Но индусам надо еще 100 лет шоб до этого додуматься..

Константин Рябицев, администратор инфраструктуры kernel.org, опубликовал результаты анализа трафика сервиса git.kernel.org, позволяющего просматривать содержимое git-репозиториев проектов, связанных с разработкой ядра Linux. Ежедневно сервис обрабатывает около 6 млн запросов информации о коммитах, из которых 66% приходятся на ботов, которых удаётся блокировать при помощи системы Anubis. 33% запросов проходят проверку системы Anubis, разрешающей вход только после подбора на языке JavaScript значения, хэш SHA-256 от которого в сочетании с выданной сервером строкой содержит определённое число лидирующих нулей (данная задача требует ресурсов CPU для решения, но не требует ресурсов для проверки).

Точно определить кто из этих 33% люди, а кто продвинутые боты, невозможно, но по характеру обращений сделан вывод, что общая доля легитимных запросов примерно 2%, а остальные 98% приходятся на скрапперы. Одним из признаков ботов рассматриваются прямые запросы старых коммитов в случайных старых ветках, которые маловероятно, что могут понадобиться людям в работе. Активность ботов создаёт огромную паразитную нагрузку на серверы так как вместо того, чтобы один раз загрузить весь код и историю коммитов через операцию «git clone» боты отправляют миллиарды запросов, перебирая все варианты обращения через web-интерфейс и многократно запрашивая одни и те же данные с разными параметрами.

Блокировка ботов по IP-адресам и автономным системам достаточно быстро перестала работать, так как боты перешли на отправку запросов с миллионов случайных IP-адресов из домашних или мобильных сетей, полученных в результате активности ботнетов или монетизации браузерных дополнений. С каждого адреса отправляется лишь 4-5 запросов, поэтому блокировать их на уровне межсетевого экрана бесполезно.

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

В итоге, на обслуживание запросов скрапперов в инфраструктуре kernel.org приходится тратить больше ресурсов, чем на все остальные виды легитимных операций, включая «git clone». На 5 серверах, обслуживающих git.kernel.org, в любой момент времени 14-16 из имеющихся 90 ядер CPU постоянно заняты отображением git-коммитов для ботов. Для того чтобы снизить нагрузку администраторы теперь пытаются урезать возможности сервиса, отключить некоторые ресурсоёмкие операции, ограничить анонимный доступ и сократить число доступных для навигации ссылок.

https://www.opennet.ru/opennews/art.shtml?num=66171

Компания Mozilla объявила о замене GPG-ключа, применяемого для заверения цифровой подписью артефактов релизов Firefox и Thunderbird, таких как tar-архивы, RPM-пакеты и файлы с контрольными суммами. Замена произведена в связи с инцидентом, в результате которого назашифрованная копия ключа была по недосмотру добавлена в приватный репозиторий компании на GitHub, доступный ограниченному числу участников проекта, которые имели доступ к применению ключа через внутренние сервисы.

Анализ логов аудита не выявил доказательств доступа третьих лиц к ключу во время его нахождения в репозитории на GitHub. Для большинства пользователей замена ключа не потребует выполнения каких-либо действий. Исключения составляют только пользователи, вручную проверяющие цифровые подписи или устанавливающие RPM-пакеты с официальными сборками Firefox от Mozilla. В данных случаях потребуется явно импортировать новый открытый ключ и отозвать старый.

Пользователям Fedora до выпуска 42 включительно (в Fedora 43 ключ будет заменён автоматически) и RHEL/Rocky/Almalinux необходимо выполнить:

   sudo rpm -e --allmatches gpg-pubkey-14f26682d0916cdd81e37b6d61b7b526d98f0353
   sudo rpm --import https://packages.mozilla.org/rpm/firefox/signing-key.gpg
   sudo dnf clean all

В openSUSE и SUSE:

   sudo rpm -e --allmatches gpg-pubkey-14f26682d0916cdd81e37b6d61b7b526d98f0353
   sudo rpm --import https://packages.mozilla.org/rpm/firefox/signing-key.gpg
   sudo zypper refresh

https://www.opennet.ru/opennews/art.shtml?num=66062

Позорное позорище :)

Какие есть? Кого читать? Кого слушать?

В рамках масштабного правительственного плана по обеспечению цифрового суверенитета госструктуры во Франции перейдут с проприетарной ОС Windows на Linux, пишет Les Numeriques со ссылкой на власти.

На свободное программное обеспечение в первую очередь переведут Межведомственное управление по цифровым вопросам (DINUM), Генеральное управление предприятий (DGE, управление Министерства экономики, отвечающее за инновации и развитие конкуренции), Национальное агентство кибербезопасности (ANSSI) и Управление государственных закупок (DAE) Франции. К осени все остальные министерства должны предоставить планы отказа от проприетарного американского ПО.