· | 25.03.2025 | Уязвимости в ingress-nginx, позволяющие выполнить код и захватить управление кластерами Kubernetes (54 +12) |
В развиваемом проектом Kubernetes ingress-контроллере ingress-nginx выявлены четыре уязвимости, позволяющие добиться выполнения своего кода на серверах облачных систем, использующих платформу Kubernetes, и получить полный привилегированный доступ к кластеру Kubernetes. Проблемам присвоен критический уровень опасности (9.8 из 10). Выявившие проблемы исследователи присвоили уязвимостям кодовое имя IngressNightmare и отметили, что уязвимости затрагивают около 43% облачных окружений. Уязвимости устранены в версиях ingress-nginx 1.11.5 и 1.12.1.
Ingress-контроллер выступает в роли шлюза и используется в Kubernetes для организации доступа из внешней сети к сервисам внутри кластера. Контроллер ingress-nginx является наиболее популярным и применяет сервер NGINX для проброса обращений к кластеру, маршрутизации внешних запросов и балансировки нагрузки. Проект Kubernetes предоставляет базовые ingress-контроллеры для AWS, GCE и nginx, последний из которых никак не связан с контроллером kubernetes-ingress, сопровождением которого занимается компания F5/NGINX (рассматриваемые уязвимости не затрагивают проекты, развиваемые разработчиками NGINX, упоминание nginx в названии ingress-nginx связано лишь с задействованием nginx в качестве прокси). Уязвимости позволяют неаутентифицированному атакующему добиться выполнения своего кода в контексте контроллера ingress-nginx, при возможности отправки запроса к web-обработчику Admission. В ходе сканирования сети выявлено более 6500 уязвимых кластеров Kubernetes, использующих общедоступные уязвимые контроллеры с открытым для внешних запросов обработчиком Admission. В конфигурации по умолчанию запущенный атакующим код может получить доступ к настройкам объекта Ingress, в которых, среди прочего, хранятся и учётные данные для обращения к серверам Kubernetes, что позволяет добиться привилегированного доступа ко всему кластеру. В качестве обходного пути защиты рекомендуется отключить в ingress-nginx функцию "Validating Admission Controller". Контроллер Admission запускается в отдельном pod-окружении и выполняет операцию проверки входящих ingress-объектов перед их развёртыванием. По умолчанию web-обработчик Admission принимает запросы без аутентификации из публичной сети. При выполнении проверки контроллер Admission создаёт конфигурацию для http-сервера nginx на основе содержимого полученного ingress-объекта и проверяет её корректность. Выявленные уязвимости позволяют добиться подстановки своих настроек в nginx через отправку специально оформленного ingress-объекта напрямую в контроллер Admission. Исследователи обнаружили, что некоторые свойства проверочных запросов, выставленные в поле ".request.object.annotations", напрямую подставляются в конфигурацию nginx. При этом сгенерированная конфигурация не применяется, а лишь тестируется путём запуска исполняемого файла "nginx" c опцией "-t". В частности, подстановка внешних данных в конфигурацию выполняется для параметров "mirror-target", "mirror-host" (CVE-2025-1098), "auth-tls-match-cn" (CVE-2025-1097) и "auth-url" (CVE-2025-24514). Например, в строке конфигурации "set $target {{ $externalAuth.URL }};" вместо "{{ $externalAuth.URL }}" подставляется URL, указанный в параметре "auth-url". При этом корректность URL не проверяется. Соответственно, атакующий может передать в качестве URL значение вида "http://example.com/#;\nнастройки" и подставить свои настройки в файл конфигурации. Для выполнения произвольного кода в процессе проверки конфигурации командой "nginx -t" исследователи воспользовались тем, что помимо проверки синтаксиса nginx загружает библиотеки с модулями и открывает файлы, упомянутые в конфигурации, для оценки их доступности. Среди прочего, при обработке директивы ssl_engine производится загрузка указанной в директиве разделяемой библиотеки для SSL-движка. Для загрузки своей библиотеки на сервер Kubernetes исследователи воспользовались (CVE-2025-1974) тем, что при обработке больших запросов nginx сохраняет тело запроса во временном файле, который сразу удаляется, но в файловой системе "/proc" для этого файла остаётся открытый файловый дескриптор. Таким образом, можно одновременно отправить запросы для сохранения временного файла и инициирования проверки конфигурации, в которой в директиве "ssl_engine" указан путь к дескриптору в файловой системе "/proc". Для того, чтобы файловый дескриптор длительное время оставался доступен значение "Content-Length" в запросе можно указать заведомо большим, чем фактически переданные данные (сервер будет ждать приёма оставшихся данных). Дополнительной сложностью является необходимость угадать PID процесса и номер файлового дескриптора, связанного с загруженной разделяемой библиотекой, но так как в контейнере обычно используется минимальное число запущенных процессов, нужные значения угадываются путём перебора в несколько попыток. В случае успеха и загрузки подставленной разделяемой библиотеки, атакующий может получить доступ к хранимым внутри pod-окружения параметрам, достаточным для управления всем кластером.
Для проверки использования уязвимого ingress-nginx можно выполнить команду: kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx
| ||
Обсуждение (54 +12) |
Тип: Проблемы безопасности |
Интересно
| ||
· | 25.03.2025 | Разработчики GRUB2 рассматривают возможность использования языка Rust (142 +14) |
Владимир Сербиненко, один из трёх мэйнтейнеров загрузчика GRUB2, внёсший в кодовую базу более пяти тысяч изменений, выставил на обсуждение возможность написания модулей для GRUB2 c использованием языка Rust. Владимир представил первые результаты экспериментов с добавлением поддержки Rust в GRUB2 и созданием необходимых обвязок. Для GRUB также подготовлены изменения, позволяющие использовать разделяемые библиотеки (".so", ET_DYN) для модулей, вместо связывания на уровне объектных файлов (".o", ET_REL).
Инициатива пока позиционируется как отдельный эксперимент, который не будет влиять на разработку GRUB2. В качестве оптимального применения Rust в GRUB упоминается написание модулей для новых файловых систем. Также не исключается переписывание на Rust кода для работы с дисковыми разделами и GPT. Предполагается, что использование Rust поможет проекту уменьшить вероятность появления некоторых видов ошибок, особенно в коде модулей, содержащем множество больших и сложных процедур парсинга. В феврале в результате аудита кодовой базы GRUB были выявлены 72 проблемы с безопасностью, 21 из которых признаны опасными уязвимостями, пригодными для обхода механизма верифицированной загрузки UEFI Secure Boot. 20 из 21 уязвимостей вызваны ошибками при работе с памятью, приводившими к переполнению буфера или обращению к памяти после её освобождения. Дополнительно можно отметить выпуск проекта GNU Boot 0.1 RC6, в состав которого вошли вышеотмеченные исправления уязвимостей (в самом GRUB2 исправления продолжают распространяться в виде патчей без формирования отдельного релиза). Проект GNU Boot развивает замену проприетарным прошивкам UEFI и BIOS, основанную на CoreBoot, но применяющую более жёсткие требования к включению бинарных компонентов. GNU Boot преподносится как "coreboot-libre", т.е. как редакция CoreBoot, избавленная от блобов и несвободных компонентов, по аналогии с тем, как проект Linux-libre развивает очищенный вариант ядра Linux. Отдельно развиваются похожие проекты Libreboot и Canoeboot.
| ||
Обсуждение (142 +14) |
Тип: К сведению |
| ||
· | 25.03.2025 | Windows Defender блокирует свободный драйвер WinRing0, используемый в официальном OEM-ПО (85 +12) |
Начиная с 11 марта встроенный в ОС Windows антивирусный пакет Windows Defender начал блокировать (помещать в карантин) свободный драйвер WinRing0. Драйвер используется для получения доступа из пространства пользователя к различному оборудованию, для которого не предусмотрено другого API в системе.
Драйвер WinRing0 востребован в проектах, управляющих настройками оборудования, как свободных (OpenRGB, Libre Hardware Monitor, FanControl), так и проприетарных (SignalRGB, Razer Synapse 3). Среди программ, использующих драйвер, есть официальное ПО от десятков производителей оборудования, в том числе популярных. Стоит отметить, что драйвер был подписан самостоятельно автором (разработчиком CrystalDiskMark) и принят Microsoft. Отмеченная Microsoft проблема, из-за которой произведена блокировка, связана с тем, что доступ к установленному в системе драйверу может получить любая программа, и посредством драйвера программа может манипулировать любым устройством в системе или повысить свои привилегии (CVE-2020-14979). В свете произведённой блокировки, многие компании были вынуждены отреагировать. Например, SignalRGB перевели программу на использование собственной проприетарной замены, в то время как Steelseries полностью отключили в своём ПО функциональность для вывода показателей системы на встроенные экраны их оборудования. На данный момент для WinRing0 выпущено исправление, ограничивающее использование драйвера только программами, запущенными с правами администратора, однако, из-за изменений политики Microsoft в отношении драйверов, получить для новой сборки подпись является затруднительным. Китайская компания HYTE, разрабатывающая ПО для мониторинга оборудования HYTE Nexus, в котором также используется этот драйвер, вызвалась взять бюрократическую процедуру на себя, и анонсировала, что опубликует подписанную сборку для свободного использования. Тем не менее, даже если Microsoft примет обновлённый драйвер, множество программ для управления настройками оборудования и мониторинга потребуется запускать с правами администратора или адаптировать для работы с изменённым драйвером. У драйвера WinRing0 существует единственный аналог под названием inpout32, который на данный момент не блокируется Windows Defender и антивирусами, однако он блокируется популярными античитами (наиболее известен этим Vanguard от RIOT, используемый в таких играх, как Valorant).
| ||
· | 24.03.2025 | Релиз ядра Linux 6.14 (104 +31) |
После двух месяцев разработки Линус Торвальдс представил релиз ядра Linux 6.14. Среди наиболее заметных изменений: драйвер ntsync c примитивами синхронизации Windows NT, настройка балансировки операций чтения в Btrfs RAID1, поддержка reflink в XFS в режиме realtime, возможность некэшируемого буферизированного ввода/вывода, dmem cgroup для ограничения памяти GPU, задействование io_uring в FUSE, делегирование атрибутов в NFS, поддержка атомарной записи в Device mapper, ускорение символических ссылок, управление возможностью выполнения скриптов, поддержка чипов Qualcomm Snapdragon 8 Elite, драйвер для NPU AMD.
В новую версию принято 12115 исправлений от 1984 разработчиков, размер патча - 39 МБ (изменения затронули 10170 файлов, добавлено 531586 строк кода, удалено 235999 строк). В прошлом выпуске было 14172 исправлений от 2086 разработчиков, размер патча - 46 МБ. Около 41% всех представленных в 6.14 изменений связаны с драйверами устройств, примерно 13% изменений имеют отношение к обновлению кода, специфичного для аппаратных архитектур, 14% связано с сетевым стеком, 7% - с файловыми системами и 4% c внутренними подсистемами ядра. Основные новшества в ядре 6.14:
| ||
Обсуждение (104 +31) |
Тип: Программы |
Интересно
| ||
· | 23.03.2025 | Проект Landrun развивает непривилегированную систему изоляции приложений (112 +21) |
Проект Landrun начал развитие новой системы для изолированного выполнения отдельных приложений. Для изоляции задействован LSM-модуль ядра Linux Landlock, позволяющий обойтись без выполнения привилегированных операций во время создания sandbox-окружения. По своим задачам Landrun близок к утилите Firejail, но отличается более простой реализацией, легковесностью и возможностью работы под обычным непривилегированным пользователем без поставки с флагом suid. Код проекта написан на языке Go и распространяется под лицензией GPLv2.
Механизм Landlock позволяет непривилегированным программам ограничить использование объектов ядра Linux, таких как иерархии файлов, сетевые сокеты и ioctl. В отличие от пространств имён и фильтрации системных вызовов изолированное окружение формируется ядром Linux в форме дополнительного слоя над существующими системными механизмами управления доступом. Для взаимодействия с подсистемой Landlock в утилите landrun используется библиотека go-landlock от разработчиков LandLock. Landrun позволяет снизить риск компрометации основной системы при запуске не заслуживающих доверия или потенциально уязвимых программ. Из возможностей отмечается поддержка выборочного ограничения доступа на уровне отдельных каталогов, привязка полномочий к файловыми путям (разрешение или запрет чтения, записи и исполнения) и контроль над инициированием и приёмом TCP-соединений. Например, при помощи Landrun процессу можно запретить запуск исполняемых файлов, разрешить запись только в отдельный подкаталог c данными, запретить создание слушающих сокетов для приёма сетевых соединений и разрешить отправку сетевых запросов только на указанные TCP-порты. В простейшем случае для запрета записи, запуска и сетевых возможностей программу можно выполнить командой "landrun --ro /", а для изоляции nginx можно использовать: landrun --rox /usr/bin --ro /lib,/lib64,/var/www --rwx /var/log --bind-tcp 80,443 /usr/bin/nginx В планах на будущее упоминается расширенное управление доступом к файловой системе, поддержка UDP и управление ресурсами процессов. Для ограничения доступа на уровне файловой системы требуется как минимум ядро Linux 5.13, а для сетевых ограничений - 6.8. Дополнительно можно отметить, что в кодовую базу Firejail уже приняты изменения, позволяющие использовать подсистему ядра Landlock для изоляции без suid-бита и повышения привилегий, но релиз с данной поддержкой ещё не опубликован.
| ||
Обсуждение (112 +21) |
Тип: Программы |
| ||
· | 23.03.2025 | В NixOS предложен метод защиты от подстановки бэкдоров, таких как в XZ (156 +18) |
Для включения в репозиторий пакетов nixpkgs, применяемый в дистрибутиве NixOS, предложен режим повторяемых сборок, позволяющий выявлять случаи внедрения в код бэкдоров, напоминающие инцидент с проектом XZ. Представленный метод защиты позволяет обнаружить модификации в архивах с исходным кодом релиза, отсутствующие в репозиториях с кодом.
Суть метода в том, что исходный код новой версии приложения собирается два раза - первый раз из кода, загруженного из git-репозитория, а второй из кода, распространяемого в готовых архивах. Если полученные в результате сборок бинарные файлы различаются, возникает повод для подозрений в наличии скрытых модификаций в репозитории или в архивном файле с кодом. Напомним, что в случае с проектом XZ репозиторий с кодом не содержал подозрительных изменений. Образующие бэкдор вредоносные компоненты поставлялись внутри файлов, используемых в тестовом наборе для проверки корректности работы распаковщика XZ. Бэкдор активировался на уровне системы сборки, а сам исходный код XZ совпадал с кодом из репозитория. Активирующие бэкдор m4-макросы для инструментария Automake были включены только в готовый архив с кодом и отсутствовали в репозитории. Бэкдор в XZ был внедрён злоумышленником, добившимся получения статуса сопровождающего в проекте. Внедрение бэкдора оказалось сразу не замечено из-за того, что дистрибутивы в основном собирают пакеты, загружая код из готовых архивов, так как при загрузке кода для сборки можно обойтись одной контрольной суммой для проверки целостности файла с архивом и использовать зеркала. Основное внимание при проверке кода сосредоточено на анализе содержимого репозитория, поэтому неочевидные отличия в архивах не всегда могут быть сразу выявлены. Для упрощения проверки соответствия файлов-архивов и срезов репозитория, соответствующих релизам, некоторые открытые проекты, такие как PostgreSQL, ввели в обиход систему повторяемой генерации архивов. В данном случае предоставляется инструментарий, позволяющий самостоятельно собрать из кода свой архив, полностью соответствующий готовому архиву, доступному для загрузки. Если независимо созданный архив и архив, предоставляемый основным проектом, будут отличаться - имеет место компрометация репозитория или эталонного архива. Проблема в том, что подобный метод практикуется лишь в отдельных случаях, в то время как многие проекты продолжают включение в архивы дополнительных артефактов, отсутствующих в основном репозитории, таких как man-страницы, документация, примеры, сценарии создания пакетов для дистрибутивов и дополнительные сборочные файлы. В основном такое происходит в силу исторических причин и особенностей процессов формирования релизов. Простая сверка соответствия начинки репозитория и архива в этом случае не подходит. Как выход предложено собирать бинарные файлы релиза, как из репозитория (например, можно использовать автоматически генерируемый в GitHub архив для релизного тега), так и из архива, подготовленного сопровождающим, сравнивая затем результат. В качестве эксперимента включение подобной проверки пока предложено только для пакета "xz". Если эксперимент окажется удачным проверки планируют использовать и в других пакетах в nixpkgs.
| ||
Обсуждение (156 +18) |
Тип: К сведению |
| ||
· | 22.03.2025 | Уязвимости в Pagure и OBS, допускавшие компрометацию пакетов в репозиториях Fedora и openSUSE (40 +10 ↻) |
Исследователи безопасности из компании Fenrisk раскрыли информацию об уязвимостях в инструментариях Pagure и OBS (Open Build Service), позволявших скомпрометировать инфраструктуры формирования пакетов дистрибутивов Fedora и openSUSE. Исследователи продемонстрировали возможность совершения атаки для выполнения произвольного кода на серверах с Pagure и OBS, что можно было использовать для подстановки изменений в пакеты в репозиториях Fedora и openSUSE.
В платформе Pagure, используемой в Fedora для совместной работы c кодом и метаданными пакетов, выявлены 4 уязвимости. Для эксплуатации выявленных проблем требуется наличие учётной записи в сервисе Pagure, которую может получить любой желающий (в настоящее время в Pagure.io зарегистрировано 24899 пользователей). Три проблемы позволяют прочитать файлы в системе, а одна проблемы выполнить свой код на сервере. Проблемы были выявлены 1 января 2024 года, сообщены через bugzilla.redhat.com 25 апреля 2024 года и устранены в Pagure через 3 часа.
В платформе OBS (Open Build Service), применяемой в openSUSE и некоторых других дистрибутивах для сборки пакетов, выявлена одна уязвимость (CVE-2024-22033), позволяющая выполнить свой код на сервере. Уязвимость выявлена 27 июня 2024 года, сообщена проекту openSUSE 29 июня и устранена 10 июля. Уязвимость присутствует в сервисе "obs-service-download_url", в котором отсутствовала должная проверка URL, применяемого при запуске утилиты wget из скрипта, осуществляющего загрузку исходного кода в OBS. Атакующий может указать в сервисе OBS конфигурацию формируемого пакета, в которой вместо URL для загрузки кода будет указана опция командной строки для wget, например: <services> <service name="download_url"> <param name="url">--output-document=/tmp/test</param> <param name="download-manifest">tempfile</param> </service> </services> Для обхода возвращения ошибки при попытке запустить wget без URL в примере указана опция "download-manifest", позволяющая указать список URL в отдельном файле. Вышеуказанный пример приведёт к запуску команды: /usr/bin/wget -i /srv/obs/service/XXXXX/src/tempfile -4 --output-document=/tmp/test которая позволяет записать в файл /tmp/test содержимое, загруженное по ссылке, указанной в файле /srv/obs/service/XXXXX/src/tempfile из кода, загруженного атакующим в OBS через интерфейс build.opensuse.org, допускающий свободную регистрацию. Кроме перезаписи файла на сервере, атакующий также может отправить себе любой файл, указав вместо "--output-document" опцию "--post-file", например, "--post-file=/etc/passwd". Таким образом атакующий может читать и записывать файлы на сервере, насколько позволяют права доступа, под которым выполняется сервис OBS. Для того, чтобы превратить возможность записи в файл в выполнение кода на сервере исследователи предложили метод, состоящий из двух этапов. Два этапа необходимы, так атакующий может создать файл ".wgetrc" с настройками к wget, но этого недостаточно для запуска команд. Но при этом, через ".wgetrc" можно создать условия для выполнения в системе любой программы, но без передачи ей аргументов. Для запуска произвольного кода предложено запускать программу "prove", которая обрабатывает файл конфигурации ".proverc", допускающий указание опции "--exec" для выполнения любого кода. На первом этапе через вышеотмеченные манипуляции с "download-manifest" в домашнем каталоге пользователя "obsservicerun" создаётся файл ".proverc", включающая команды, которые будут выполнены при запуске процесса "prove". На втором этапе создаётся файл
.wgetrc" с параметром "use-askpass=/usr/bin/prove", приводящим к вызову "prove". После появления данных файлов достаточно создать условия загрузки любых данных при помощи wget и это приведёт к запуску кода атакующего на сервере с правами пользователя "obsservicerun". Прав пользователя "obsservicerun" достаточно для извлечения из репозиториев ключей, используемых пользователями OBS для заверения пакетов.
Дополнение: Команда SUSE Product Security считает, что опасность уязвимости в OBS переоценена и заявление исследователей о том, что проблема позволяет скомпрометировать все пакеты в дистрибутиве openSUSE не соответствует действительности. Отмечается, что сервисы в инфраструктуре build.opensuse.org запускаются с использованием изолированных контейнеров, заново создаваемых и не содержащих критичной информации. Выявленная уязвимость оценена как опасная, но недостаточная для компрометации сборочной инфраструктуры openSUSE и формируемых пакетов. Кроме того, указано что действия в интерфейсе OBS, описанные в примере атаки, могли быть совершены только в варианте OBS, локально установленном на рабочей станции разработчика.
| ||
Обсуждение (40 +10 ↻) |
Тип: Проблемы безопасности |
Интересно
| ||
· | 22.03.2025 | Выпуск операционной системы ReactOS 0.4.15 (460 +47) |
После более трёх лет разработки представлен релиз операционной системы ReactOS 0.4.15, нацеленной на обеспечение совместимости с программами и драйверами Microsoft Windows, а также предлагающий оформление в стиле Windows. Для загрузки подготовлены установочный ISO-образ (117 МБ) и Live-сборка (в zip-архиве 85 МБ). Код проекта распространяется под лицензиями GPLv2 и LGPLv2.
После прошлого выпуска внесено более 8600 изменений и закрыто 1319 отчётов о проблемах. Ключевые изменения:
В master-ветке дополнительно развивается поддержка UEFI, SMP и управления энергопотреблением, добавлены графический инсталлятор и драйвер NTFS.
| ||
Обсуждение (460 +47) |
Тип: Программы |
| ||
· | 21.03.2025 | Google развивает систему перезагрузки ядра без остановки работы устройств (75 +38) |
Инженеры из компании Google опубликовали для обсуждения разработчиками ядра Linux набор патчей с реализацией подсистемы Live Update Orchestrator (LUO), предназначенной для обновления ядра в Live-режиме. В отличие от таких механизмов, как livepatch, Ksplice, kpatch и kGraft, новая система не ограничивается возможностью применения отдельных исправлений к работающему ядру Linux, а позволяет полноценно перезагрузить и обновить ядро без остановки работы отдельных устройств. Проект базируется на наборе патчей KHO (Kexec HandOver) к механизму kexec, применяемому для загрузки нового ядра из уже запущенного ядра Linux без физической перезагрузки.
В качестве основной области применения LUO называются облачные окружения, в которых появится возможность обновления гипервизора KVM без нарушения работы запущенных виртуальных машин. В частности, можно будет приостановить виртуальные машины на время перезагрузки ядра с гипервизором, сохранив в рабочем состоянии все прикреплённые к виртуальным машинам устройства. Для воплощения данной возможности LUO предоставляет возможности для сохранения состояния устройств до переключения на новое ядро и восстановления состояния сразу после задействования нового ядра таким образом, что непрерывные операции системы и приложений в пространстве пользователя с устройствами не будут нарушены. В процессе перезагрузки ядра также обеспечена неразрывность выполняемых операций с DMA и активность, связанная с обработкой прерываний. Для координации сохранения состояния и переключения на новое ядро LUO предоставляет API, позволяющий другим подсистемам ядра подключать обработчики для отслеживания и участия в процессе Live-перезагрузки. Среди подсистем, которые могут интегрироваться с LUO, отмечены гипервизор KVM, iommu, система прерываний и драйверы. Для передачи состояния памяти от старого ядра к новому задействован KHO (Kexec HandOver). Управление производится через файлы sysfs "/sys/kernel/liveupdate/{state, prepare, finish}".
| ||
Обсуждение (75 +38) |
Тип: К сведению |
| ||
· | 21.03.2025 | Перегрузка инфраструктуры KDE, GNOME, Fedora, Codeberg и SourceHut из-за ИИ-индексаторов (203 +32) |
Различные открытые проекты столкнулись с волной сбоев и замедления работы элементов инфраструктуры из-за повышения активности индексаторов содержимого сайтов (скраперов), собирающих информацию для обучения больших языковых моделей или для обеспечения ИИ-поиска в Web (например, компания Anthropic вчера представила вариант модели Claude 3.7 с возможностью поиска в Web).
Проблемы возникают из-за того, что подобные ИИ-индексаторы действуют агрессивно, собирают информацию в несколько потоков и не учитывают правила доступа к контенту, заданные на сайтах через файл robots.txt. Проблему усугубляет то, что разработками в области машинного обучения занимаются большое число разных компаний по всему миру, которые пытаются собирать как можно больше данных в меру своих возможностей. Каждая компания запускает свой индексатор и все вместе они создают огромную паразитную нагрузку на элементы инфраструктуры. После начала блокировки подобного трафика некоторые индексаторы начали притворяться типовыми браузерами для обхода фильтрации по идентификатору User Agent и использовать распределённые сети, охватывающие большое число хостов, для преодоления ограничений интенсивности обращений с одного IP. Наиболее сильно из-за активности ИИ-индексаторов страдают инфраструктуры открытых проектов, использующих собственные хостинги Git-репозиториев, форумы и Wiki, которые изначально не были рассчитаны на обработку высокой нагрузки. Проблемы возникли у платформы совместной разработки SourceHut, развиваемой Дрю ДеВолтом (Drew DeVault), автором пользовательского окружения Sway. Дрю сетует на то, что в очередной раз вместо того, чтобы заниматься развитием платформы ему приходится тратить большую часть своего времени на разгребание неожиданно возникших проблем. Четыре года назад проблемой для SourceHut стало использование CI-инфраструктуры для майнинга криптовалют. Два года назад пришлось разбираться с флудом запросами "git clone" из-за сервиса Go Module Mirror. В прошлом году платформа была выведена из строя на неделю из-за DDoS-атаки. Теперь возникла новая напасть - ИИ-индексаторы. По словам Дрю, решение нескольких приоритетных задач было отложено на недели или даже месяцы из-за того, что создателей SourceHut постоянно отвлекает блокировка ИИ-ботов. Чтобы избежать сбоев правила блокировки приходится пересматривать по несколько раз в день. Для снижения запросов к ресурсоёмким обработчикам в SourceHut были внедрены ловушки на базе инструментария Nepenthes, генерирующего в ответ на запросы ботов случайный контент с зацикленными на ловушку ссылками. До этого разработчики SourceHut из-за агрессивного поведения ИИ-ботов были вынуждены заблокировать трафик из нескольких облачных платформ, включая Google Cloud Platform и Azure. При этом введённые меры не лишены ложных срабатываний, от чего уже пострадали многие пользователи, так как внедрённая система блокировки не всегда может отличить реальных пользователей от ботов (например, возникли проблемы со сборкой пакетов для репозиториев Nix). ИИ-боты сканируют всё до чего могут дотянуться, включая ресурсоёмкие операции, такие как "git blame", перебирают каждую страницу в "git log" каждого репозитория, мимикрируя под запросы обычных пользователей, используя случайные индинтификаторы реальных браузеров (User Agent) и отправляя запросы с десятков тысяч IP, не связанных с какой-то одной подсетью. Другие проекты, обратившие внимание на проблему:
Администраторы микроблогинговой платформы Framapiaf подготовили список блокировки, насчитывающий 460 тысяч адресов с которых зафиксирована активность ИИ-ботов. Отдельно развивается проект ai.robots.txt, собравший список идентификаторов (User Agent) ИИ-индексаторов, которые не скрывают имя бота, а также опубликовавший статистику о том, какие из ботов учитывают правила из файла robots.txt. Примеры блокировки по заголовку User-Agent предложены для Apache httpd и nginx. Дополнительно можно отметить ловушку для ИИ-ботов AI Labyrinth, представленную вчера компанией Cloudflare. Пользователям Cloudflare предоставлена опция, позволяющая вместо блокировки ИИ-ботов, игнорирующих запрет на индексацию, отдавать фиктивные страницы и зацикливать ботов на их обработке. Предполагается, что выдача ИИ-ботам мусорного контента заставит их разработчиков следовать правилам robots.txt и снизить интенсивность запросов. По статистике Cloudflare около 1% всего трафика в сети приходится на ИИ-ботов.
| ||
Обсуждение (203 +32) |
Тип: К сведению |
Интересно
| ||
· | 20.03.2025 | Браузер Chrome переведён на шрифтовой движок Skrifa, написанный на Rust (242 +18) |
Компания Google перевела браузер Chrome на библиотеку Skrifa, написанную на языке Rust и предоставляющую возможности для обработки шрифтов в формате OpenType. Skrifa реализует подмножество возможностей шрифтового движка FreeType, необходимое для 2D-библиотеки Skia, применяемой в Chrome и Chromium. Для избавления библиотеки Skia от привязки к движку FreeType создан новый шрифтовой бэкенд, основанный на Skrifa.
В Chrome 128 написанный на Rust бэкенд был включён в экспериментальном режиме для редко используемых форматов шрифтов, таких как CFF2 и цветные шрифты. Начиная с выпуска Chrome 133 новый бэкенд задействован для всех web-шрифтов в сборках для платформ Linux, Android и ChromeOS. На платформах Windows и macOS новый движок пока используется в качестве запасного и применяется в случае, если система не поддерживает формат шрифта, который пытается отобразить браузер. Код Skrifa разработан инженерами Google в рамках инструментария Fontations и открыт под лицензиями MIT и Apache 2.0. Для проверки корректности работы Skrifa подготовлено около 700 unit-тестов. Библиотека поддерживает декодирование глифов в форматах glyf, CFF, CFF2, COLRv0, COLRv1, EBDT, CBDT и sbix, вариативные шрифты в форматах glyf, CFF2 и COLRv1, хинтиг шрифтов в форматах glyf, CFF и CFF2. Помимо библиотеки Skrifa, предоставляющей API для доступа к метаданным шрифтов и загрузки контуров глифов, инструментарий Fontations включает низкоуровневые библиотеки для чтения, разбора, изменения и создания шрифтовых данных в формате OpenType. В свою очередь Fontations является частью проекта Oxidize, созданного для перевода утилит и библиотек для работы с текстом и шрифтами с компонентов на языках Python (fonttools, fontmake, nanoemoji) и C++ (HarfBuzz, FreeType) на новые реализации, написанные на Rust. Разработка компонентов на Rust началась из-за недостаточной эффективности выявления ошибок при помощи fuzzing-тестирования, так как форматы шрифтов слишком сложны для охвата всех возможных комбинаций. Например, на прошлой неделе во FreeType была выявлена критическая уязвимость, позволяющая выполнить код при обработке специально оформленных шрифтов из переполнения буфера. Помимо движка FreeType проблемы с обеспечением безопасности могут создавать и используемые в нём зависимости, такие как bzip2, libpng и zlib. Использование Rust позволило значительно снизить вероятность появления проблем при работе с памятью, повысить качество кода, снизить затраты времени на исправление проблем с безопасностью и ускорить внесение улучшений в возможности Chrome, связанные со шрифтами. По статистике Google и Microsoft около 70% опасных уязвимостей вызваны проблемами при работе с памятью, которых можно избежать при использовании языка Rust без unsafe-блоков. Например, использование Rust, позволило бы избежать ранее выявлявшихся в коде FreeType проблем, связанных с обращением к освобождённым областям памяти, выходом за границу буфера, доступом к массивам без проверки индексов, целочисленными переполнениями, некорректным использованием необнулённых областей памяти и ошибками приведения типов.
| ||
Обсуждение (242 +18) |
Тип: К сведению |
| ||
· | 20.03.2025 | Выпуск miracle-wm 0.5, композитного менеджера на базе Wayland и Mir (48 +7) |
Мэтью Косарек (Matthew Kosarek), разработчик из компании Canonical, опубликовал выпуск композитного менеджера miracle-wm 0.5, использующего протокол Wayland и компоненты для построения композитных менеджеров Mir. Miracle-wm поддерживает мозаичную (tiling) компоновку окон, схожую с аналогичной в проектах i3 и Sway. В качестве панели может применяться Waybar. Код проекта написан на языке C++ и распространяется под лицензией GPLv3. Готовые сборки сформированы в формате snap, а также в пакетах rpm и deb для Fedora и Ubuntu.
Целью miracle-wm является создание композитного сервера, применяющего мозаичное управление окнами, но более функционального и стильного, чем такие продукты, как Swayfx. При этом проект позволяет использовать и классические приёмы работы с плавающими окнами, например, можно размещать отдельные окна поверх мозаичной сетки или закреплять окна к определённому месту на рабочем столе. Поддерживается виртуальные рабочие столы с возможностью выставления для каждого рабочего стола своего режима работы с окнами по умолчанию (мозаичная компоновка или плавающие окна). Предполагается, что miracle-wm может оказаться полезным пользователям, которые отдают предпочтение мозаичной компоновке, но желают получить визуальные эффекты и более яркое графическое оформление с плавными переходами и цветами. Конфигурация определяется в формате YAML. Для установки miracle-wm можно использовать команду "sudo snap install miracle-wm --classic". ![]() Основные новшества:
| ||
Обсуждение (48 +7) |
Тип: Программы |
| ||
· | 19.03.2025 | Выпуск среды рабочего стола GNOME 48 (235 +26) |
После шести месяцев разработки представлен выпуск среды рабочего стола GNOME 48. Для быстрой оценки возможностей GNOME 48 предложены специализированные Live-сборки на основе openSUSE и установочной образ, подготовленный в рамках инициативы GNOME OS. GNOME 48 также уже включён в состав экспериментальных сборок Ubuntu 25.04 и Fedora 42.
| ||
Обсуждение (235 +26) |
Тип: Программы |
| ||
· | 19.03.2025 | Выпуск Java SE 24 и OpenJDK 24 (91 +7) |
После шести месяцев разработки компания Oracle опубликовала платформу Java SE 24 (Java Platform, Standard Edition 24), в качестве эталонной реализации которой используется открытый проект OpenJDK. За исключением удаления некоторых устаревших возможностей в Java SE 24 сохранена обратная совместимость с прошлыми выпусками платформы Java - большинство ранее написанных Java-проектов без изменений будут работоспособны при запуске под управлением новой версии. Готовые для установки сборки Java SE 24 (JDK, JRE и Server JRE) подготовлены для Linux (x86_64, AArch64), Windows (x86_64) и macOS (x86_64, AArch64). Разработанная в рамках проекта OpenJDK эталонная реализация Java SE 24 полностью открыта под лицензией GPLv2 с исключениями GNU ClassPath, разрешающими динамическое связывание с коммерческими продуктами.
Java SE 24 отнесён к категории выпусков с обычным сроком поддержки, обновления для которого будут выпускаться до следующего релиза. В качестве ветки с длительным сроком поддержки (LTS) следует использовать Java SE 21 или Java SE 17, обновления для которых будут выпускаться до 2031 и 2029 годов соответственно (общедоступные - до 2028 и 2026 годов). Расширенная поддержка LTS-ветки Java SE 8 продлится до 2030 года, а Java SE 11 - до 2032 года. Следующим LTS-релизом станет осенний выпуск Java SE 25. Среди предложенных в Java SE 24 новшеств:
Дополнительно можно отметить публикацию обновления платформы для создания приложений с графическим интерфейсом JavaFX 24 и новый выпуск универсальной виртуальной машины GraalVM, поддерживающей запуск приложений на JavaScript (Node.js), Python, Ruby, R, любых языках для JVM (Java, Scala, Clojure, Kotlin) и языках, для которых может формироваться биткод LLVM (C, C++, Rust). Кроме поддержки JDK 24 в новой версии GraalVM проведены оптимизации для задач, связанных с машинным обучением, улучшена поддержка компиляции Java-байткода в машинный код, добавлен механизм SkipFlow для сокращения размера исполняемых файлов и уменьшения времени компиляции.
| ||
Обсуждение (91 +7) |
Тип: Программы |
| ||
· | 19.03.2025 | Представлены две модели умных часов на открытой платформе PebbleOS (102 +26) |
Эрик Мигиковски (Eric Migicovsky), основатель компании Pebble Technology, представил две новые модели умных часов, которые будут выпускаться на базе открытой платформы PebbleOS. Новые модели полностью совместимы с приложениями и темами оформления, разработанными для старых часов Pebble. Устройства являются усовершенствованными вариантами ранее выпускаемых часов Pebble 2 и Pebble Time 2, и отличаются увеличением автономной работы с 7 до 30 дней, громкоговорителем, иным вибросигналом, улучшенными кнопками, датчиками давления и магнитного поля.
Прошлые модели часов Pebble выпускались с 2013 по 2016 год и пользовались популярностью благодаря длительной автономной работе из-за экрана не базе электронной бумаги и возможности установки на часы дополнительных программ из каталога, насчитывающего более 10 тысяч приложений. В 2016 году производство и разработка часов Pebble были свёрнуты после поглощения компанией Fitbit. В 2021 году компания Fitbit была куплена корпорацией Google, которая в январе 2025 года открыла код операционной системы PebbleOS под лицензией Apache 2.0 в рамках инициативы по поддержке энтузиастов, заинтересованных в продолжении развития платформы. Основатель Pebble воспользовался публикацией PebbleOS для возрождении проекта и разработал две новые модели часов - "Core 2 Duo" и "Core Time 2". Между собой новые модели отличаются использованием 1.26-дюймового черно-белого (144x168) и 1.5-дюймового цветного сенсорного (200x228) экрана на базе электронной бумаги, а также пластиковым и металлическим корпусом. В остальном параметры часов близки. Модель Core 2 Duo доступна для предзаказа по цене $149, а Core Time 2 - $225. Производство первой модели начнётся в июле, а второй в декабре. У часов Core 2 Duo 1.26-дюймовый черно-белый экран и корпус идентичен ранее выпускаемой модели Pebble 2. Устройство тоже доступно в черном и белом исполнении, защищено от попадания влаги (IPX8), имеет встроенный микрофон, функции отслеживания продолжительности сна и шагомер. Отличия от Pebble 2 сводятся к автономной работе в течение 30 суток, задействованием Bluetooth LE чипа Nordic nRF52840, наличием громкоговорителя, барометра, компаса, линейного резонансного привода (тише и мощнее вибромотора) и более надёжными 4 кнопками. ![]() Модель Core Time 2 оснащена 64-цветным 1.5-дюймовым экраном на базе электронной бумаги, превышающим экран модели Pebble Time 2, выполненный по той же технологии, на 53% по размеру и на 88% по числу пикселей. Экран сенсорный и накрыт плоской стеклянной линзой, которая в отличие от изогнутой линзы часов Pebble Time 2 вносит меньше искажений и бликов. Корпус и 4 кнопки выполнены из металла. Обеспечен уровень защиты от попадания влаги IPX8. Время автономной работы заявлено в 30 дней. Помимо функций отслеживания продолжительности сна и шагомера, часы укомплектованы пульсометром. Имеется микрофон и громкоговоритель. ![]() Новые модели созданы в соответствии со следующими принципами:
Прошивки для устройств построены на открытом коде платформы PebbleOS и поддерживают все основные возможности старых часов Pebble, такие как вывод уведомлений и сообщений со смартфона (например, уведомления о входящих звонках и событиях календаря-планировщика, информация о новых SMS, email и сообщениях из популярных мессенджеров), списки действий, смена тем оформления экрана, будильник, таймер, календарь, управление воспроизведением музыки, функции фитнес-трекера, расширение функциональности через установку приложений из каталога apps.rebble.io. Для Android и iOS будут опубликованы новые сопутствующие приложения для взаимодействия смартфона с умными часами.
| ||
Обсуждение (102 +26) |
Тип: К сведению |
| ||
Следующая страница (раньше) >> |
Закладки на сайте Проследить за страницей |
Created 1996-2025 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |