Компания BMW открыла систему распределённой 3D-отрисовки RAMSES

Компания BMW открыла исходные тексты проекта RAMSES (Rendering Architecture for Multi-Screen EnvironmentS), в рамках которого подготовлена распределённая система отрисовки 3D-контента, сфокусированная на обеспечении высокой эффективности с позиции потребления ресурсов при использовании на встраиваемых системах и пропускной способности при трансляции вывода по сети. Код написан на языке C++ и распространяется под лицензией MPL 2.0 (Mozilla Public License).

Проект разработан в процессе оптимизации отрисовки контента в автомобильных информационно-развлекательных системах, содержащих несколько экранов и вычислительных устройств. RAMSES представляет собой прослойку, позволяющую применить клиент-серверную модель для отрисовки, при которой один процесс формирует 3D-контент, а другой занимается его отрисовкой. При этом процессы могут выполняться на другом устройстве или в разных виртуальных окружениях.

Более того, один вещающий процесс может передавать содержимое на несколько процессов отрисовки (отображение на разных экранах), несколько процессов отрисовки могут вещать через один процесс отрисовки (работа с несколькими приложениями на одном экране) или смешивая оба варианта (работа с несколькими приложениями на нескольких экранах). В итоге формируется своеобразный дисплейный кластер, в которых входит набор имеющихся экранов и вычислительных устройств. Элементы в дисплейном кластере работают как единая экосистема, при том, что в состав кластера могут входить устройства на базе разных платформ (встраиваемые, настольные) и операционных систем (Windows, Linux) с различными графическими стеками (Wayland, X11, WGL, Integrity OS).

RAMSES предоставляет обвязку вокруг существующих реализаций OpenGL, позволяющую применять предлагаемую модель распределённой отрисовки для любых OpenGL-приложений. Поддерживается работа с различными версиями OpenGL (OpenGL ES 3.0+, OpenGL 4.2, 4.5 и т.п.), что позволяет использовать одну кодовую базу на различных платформах, предоставляющих разные версии OpenGL.

RAMSES также предоставляет собственный низкоуровневый API, близкий к OpenGL. Данный API упаковывает команды и ресурсы OpenGL для минимизации трафика между клиентом и сервером, что позволяет передавать высококачественный 3D-контент поверх обычных сетей для отображения без задержек и разрывов. Для ускорения загрузки и запуска, данные сцен и связанные с ними ресурсы (текстуры, шейдеры и т.п.) могут быть сериализированы в файлы и прокэшированы на стороне, отвечающей за отображение.

Минимальным обрабатываемым элементом контента является сцена. Например, мультимедийный проигрыватель может сформировать две сцены — одну с основным интерфейсом для мультимедийного экрана, а другую со списком песен для отображения на приборной панели. Сцены от разных приложений могут совмещаться на одном экране, например, в вышеприведённом примере список песен может быть совмещён с интерфейсом приборной панели.

Источник: [ссылка]

Для гипервизора KVM реализована возможность запуска гостевых систем Xen

Жуан Мартинс (Joao Martins) из компании Oracle предложил для обсуждения разработчиками ядра Linux набор патчей, добавляющий в гипервизор KVM возможности запуска не модифицированных гостевых систем Xen в режиме HVM c использованием всех уже имеющиеся бэкендов (драйверы на стороне хост-окружения (Dom0), применяемые для обеспечения работы гостевой ОС) и фронтэндов (драйверы на стороне гостевой ОС (DomU) для взаимодействия с бэкенд-драйверами хост-окружения, например драйверы сетевой, графической и дисковых подсистем).

В KVM поддержка гостевых систем Xen может оказаться полезной для переноса существующих образов гостевых систем из инфраструктур на базе Xen или для создания полигонов для тестирования и разработки гостевых систем для Xen, а также для использования имеющихся паравиртуальных драйверов (PV) Xen. На стороне гипервизора реализация напоминает подход, применённый в KVM для запуска вложенных виртуальных машин HyperV. На стороне бэкенда предлагается использовать штатные драйверы Xen.

В отличие от развивавшегося около 10 лет назад модуля xenner, обеспечивающего эмуляцию Xen Dom0 через KVM, в предложенном наборе патчей обеспечена возможность применения существующих паравиртуальных драйверов Xen (вместо полной эмуляции оборудования, для ввода/вывода, обработки прерываний и взаимодействия с оборудованием на стороне гостевой системы применяются специальные драйверы, работающие через бэкенд-драйверы хост-системы). Более того, кроме бэкнд и фронтэнд драйверов Xen для управления можно использовать штатный инструментарий Xen, так как в предложенных для KVM патчах воплощён необходимый для их работы UABI. Например, можно запускать не модифицированные версии xenstored, xenstore-list и xenstore-read.

Патчи разбиты на две основные части:

  • Код для поддержки Xen HVM ABI, позволяющий загружать гостевые системы в режиме HVM без применения на стороне гостевой системы паравиртуализированных драйверов.
  • Код для поддержки паравиртуальных (PV) драйверов, обеспечивающий перенаправление гипервызовов, эмулируя поведение PV бэкендов Xen, и реализующий специфичные для Xen механизмы для работы с разделяемой памятью и каналами для уведомления о наступлении различных событий.

Дополнительно можно отметить выявление трёх уязвимостей в KVM, которые были исправлены в обновлениях ядра Linux 4.20.8, 4.19.21, 4.14.99 и 4.9.156:

  • CVE-2019-7222 — утечка памяти, позволяющая в гостевой системе, запущенной с использованием вложенной виртуализации, получить доступ к отрывкам памяти ядра хост-системы. Проблема вызвана отсутствием очистки памяти перед использованием в структуре kvm_inject_page_fault;
  • CVE-2019-7221 — возможность обращения к уже освобождённой области памяти (use-after-free) в коде эмуляции таймера vmx. Уязвимость может быть эксплуатирована из гостевой системы, запущенной с использованием вложенной виртуализации, и потенциально может привести к выполнению своего кода на стороне хост-системы;
  • CVE-2019-6974 — установка файлового дескриптора устройства до создания ссылки на него может применяться для создания условий use-after-free и повышения своих привилегий в системе. Проблему можно эксплуатировать на стороне хоста, при наличии у пользователя доступа к /dev/kvm.

Источник: [ссылка]

Компания Redis Labs перешла с Commons Clause на собственную несвободную лицензию

Компания Redis Labs, развивающая СУБД Redis, объявила об очередной смене лицензии на дополнительные модули, в которых предлагаются расширенные возможности для корпоративных пользователей (RediSearch, RedisGraph, RedisJSON, RedisML, RedisBloom и т.п.). Вместо ранее применяемой лицензии Apache 2.0 с дополнением «Commons Clause», вводящей ограничение на продажу, модули отныне будут поставляться под отдельной проприетарной лицензией RSAL (Redis Source Available License). Основной код Redis остаётся свободным и продолжает поставляться под лицензией BSD.

Лицензия RSAL по своим целям напоминает ранее принятую проектом MongoDB лицензию SSPL, которая была причислена к числу несвободных лицензий, недопустимых для использования в репозиториях Fedora. RSAL базируется на принципах разрешительной лицензии BSD, но вводит ограничения на некоторые области использования. Так как текст RSAL приводит к дискриминации отдельных категорий пользователей, данная лицензия не может считаться открытой или свободной, а продукты под данной лицензией не могут включаться в свободные дистрибутивы, такие как Fedora и Debian.

RSAL позволяет использовать, изменять, распространять и интегрировать код в приложения (в том числе в платные), за исключением случаев, когда эти приложения являются СУБД, движками кэширования, поисковыми системами, движками потоковой обработки данных, системами индексации данных и движками для систем машинного обучения и искусственного интеллекта. Иными словами, без покупки коммерческой лицензии развиваемые в Redis Labs модули теперь не могут включаться в состав таких продуктов, как СУБД или поисковые движки, но сам Redis по-прежнему не ограничен в использовании.

В качестве причины перевода модулей на проприетарную лицензию отмечается желание не допустить паразитирования провайдеров облачных сервисов на открытом ПО. Компания Redis Labs столкнулась с ситуацией, когда облачные провайдеры создают производные коммерческие продукты и занимаются перепродажей открытых модулей к Redis в виде облачных сервисов, но не принимают участия в жизни сообщества и не помогают в разработке. Создаётся ситуация когда выгоду получают ничем не связанные с проектом облачные провайдеры, перепродающие готовые открытые решения, а непосредственно разработчики остаются ни с чем.

Причиной создания отдельной лицензии, вместо ранее применяемой лицензии Apache 2.0 c примечанием Commons Clause стало желание избавиться от путаницы и неопределённости в отношении условий использования (например, в Commons Clause ограничения применяются в зависимости от «значительности использования», но критерий значительности точно не определён). Кроме того, Commons Clause распространяет ограничение на оказание услуг поддержки, что мешает формированию экосистемы вокруг модулей к Redis.

До перехода на Commons Clause применялась лицензия AGPL , которая не помогла избавиться от проблем, так как требовала возвращать изменения и развивать производный продукт под той же лицензией, но не мешала организовывать работу платных сервисов на основе уже предоставляемого кода. Напомним, что в ответ на переход к условиям Commons Clause представители сообщества основали проект GoodFORM, в рамках которого создали форки модулей Redis и продолжили их разработку под лицензией AGPLv3.

Источник: [ссылка]

Linux Foundation запустил проект по разработке Linux-окружения для высоконадёжных систем

Под эгидой организации Linux Foundation запущен новый проект ELISA (Enabling Linux in Safety Application), нацеленный на применение Linux в решениях, требующих повышенной надёжности (Safety-Critical Systems), сбой в которых может угрожать жизни людей, нанести вред окружающей среде или привести к серьёзным повреждениям оборудования. Учредителями нового проекта выступили компании Arm, BMW, KUKA, Linutronix и Toyota.

В рамках проекта планируется разработать инструменты и процессы для созданий и сертификации решений повышенной надёжности на базе Linux и открытого ПО, которые можно применять в таких областях, как транспорт, производство, здравоохранение и энергетика. Например, подготовленное Linux-окружение сможет применяться для оснащения промышленных роботов, медицинских устройств, систем автоматизации производства, автомобильных систем и автономных транспортных средств.

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

В качестве основы ELISA легли наработки проектов SIL2LinuxMP (урезанное окружение GNU/Linux для RTOS) и Real-Time Linux (PREEMPT_RT). Можно отметить, что в прошлом году была проведена большая работа по приведению патчей PREEMPT_RT к требованиям, необходимым для включения в основной состав ядра Linux. В частности была пересмотрена архитектура, переписан код, переработана инфраструктура обработки прерываний, учтены пожелания по использованию printk. После завершения тестирования патчей PREEMPT_RT отдельные изменения планируют поэтапно продвигать в основной состав ядра.

Задачу усложняет то, что реализация режима реального времени требует внесения значительных изменений в различные ключевые подсистемы ядра, включая таймеры, планировщики задач, механизмы блокировки и обработчики прерываний, а также необходимо чтобы все драйверы устройств отвечали определённым требованиям для работы в режиме real-time. Из-за подобных сложностей трудно прогнозировать время интеграции наработок PREEMPT_RT в основное ядро, но утверждается, что рано или поздно это будет сделано.

Источник: [ссылка]

Проект Tor представил OnionShare 2, приложение для защищённого обмена файлами

Проект Tor представил выпуск утилиты OnionShare 2, позволяющей безопасно и анонимно передавать и получать файлы, а также организовать работу публичного файлообменника. Код проекта написан на языке Python и распространяется под лицензий GPLv3. Готовые пакеты подготовлены для Ubuntu, Fedora, Windows и macOS.

OnionShare запускает на локальной системе web-сервер, работающий в форме скрытого сервиса Tor, и делает его доступным для других пользователей. Для доступа к серверу генерируется непредсказуемый onion-адрес, который выступает в роли точки входа для организации обмена файлами (например, «http://ash4…pajf2b.onion/slug», где slug — два случайных слова для усиления защиты). Для загрузки или отправки файлов другим пользователям достаточно открыть этот адрес в Tor Browser. В отличие от отправки файлов по email или через такие сервисы, как Google Drive, DropBox WeTransfer, система OnionShare является самодостаточной, не требует обращения к внешним серверам и позволяет передать файл без посредников напрямую со своего компьютера.

От других участников обмена файлами не требуется установка OnionShare, достаточно обычного Tor Browser и одного экземпляра OnionShare у одного из пользователей. Конфиденциальность пересылки осуществляется путём безопасной передачи адреса, например, используя режим end2end-шифрования в мессенджере. После завершения передачи адрес сразу удаляется, т.е. передать файл второй раз в обычном режиме не получится (требуется применение отдельного публичного режима). Для управления отдаваемыми и принимаемыми файлами, а также для контроля за передачей данных, на стороне запущенного на системе пользователя сервера предоставляется графический интерфейс.

В новом выпуске:

  • Добавлена возможность не только отдавать свои файлы, но и принимать файлы других пользователей. Для загрузки файлов от других пользователей генерируется отдельный адрес;
  • Реализован публичный режим работы, который позволяет нескольким пользователям загрузить или отправить файлы. По умолчанию по прежнему генерируются одноразовые адреса, которые удаляются сразу после завершения передачи. В публичном режиме адрес не меняется, а прекращение обмена и удаление адреса производится вручную;
  • Комбинация постоянного адреса и режима отправки позволяет создавать простейшие совместные хранилища типа DropBox или организовать анонимую передачу сведений журналистам и правозащитникам, не раскрывая источник утечки данных;
  • Добавлена поддержка третьей версии протокола onion-сервисов;
  • Реализован запуск версии для macOS в режиме sandbox-изоляции;
  • В случае передачи только одного файла отныне не применяется его упаковка в zip-архив (zip формируется только при выборе нескольких файлов или каталогов);
  • Обеспечена полная поддержка Tor-транспорта meek_lite, существенно упрощающего подключение к Tor в странах с жесткой цензурой. Для обхода блокировок используется проброс через облачную платформу Microsoft Azure;
  • Добавлена возможность выбора языка интерфейса и реализован перевод на русский язык;
  • Значительно переработана кодовая база проекта. Для контроля за качеством продукта релизовано unit-тестирование.

Источник: [ссылка]

Уязвимость в ядре Linux, позволяющая повысить свои привилегии в системе

В ядре Linux выявлена уязвимость (CVE-2019-8912), которая позволяет непривилегированному пользователю выполнить свой код на уровне ядра. По мнению некоторых поставщиков потенциально возможно нахождение векторов для эксплуатации уязвимости по сети, но данные сведения пока не подтверждены. В том числе Национальный институт стандартов и технологий США (NIST) отметил проблему как удалённо эксплуатируемую и легко воспроизводитмую.

Уязвимость вызвана ошибкой в реализации функции af_alg_release(), представленной в файле crypto/af_alg.c. Игнорирование установки значения NULL в некоторых полях структуры sockfs_setattr (sock->sk не выставлялся в NULL) может привести к обращению к уже освобождённым областям памяти (use-after-free) и созданию условий для выполнения кода непривилегированного локального пользователя в контексте ядра. Прототип эксплоита пока не подготовлен (потенциально атака может быть совершена через манипуляции с Crypto API с использованием сокета с типом AF_ALG).

Проблема была найдена в результате использования разработанного компанией Google анализатора KASAN (KernelAddressSanitizer), нацеленного на выявление ошибок при работе с памятью и фактов некорректного обращения к памяти, таких как обращения к освобождённым областям памяти и помещение кода в области памяти, не предназначенные для подобных манипуляций. KASAN был добавлен в состав ядра 4.0 и включается опцией «CONFIG_KASAN=y».

Уязвимость проявляется начиная с ветки ядра 2.6 и устранена в сегодняшних обновлениях ядра 4.20.11, 4.19.24, 4.14.102, 4.9.159, 4.4.175 и 3.18.135. Из дистрибутивов обновление пока выпущено только для Fedora. В Debian и Ubuntu уязвимость остаётся неисправленной. В ядрах из состава SUSE 11/12 и Red Hat Enterprise Linux 5/6/7 проблема не проявляется (не может быть эксплуатирована).

Источник: [ссылка]

Проект KDE перешёл на Matrix для общения разработчиков

Проект KDE объявил о внедрении децентрализованного сервиса для общения разработчиков, построенного с использованием открытой платформы Matrix. Инфраструктура для обмена сообщениями основана на собственном экземпляре сервера Matrix (kde.modular.im), поддержанием которого будут заниматься участники проекта KDE.

Matrix выбран в качестве основной платформы для общения разработчиков после нескольких лет изучения возможных альтернатив чатам на основе протокола IRC. Долгое время IRC решал задачи организации общения, но используемые в KDE IRC-каналы размещены на серверах Freenode, не подконтрольных сообществу. Кроме того, IRC непривычен для новичков и не обеспечивает функциональности, к которой привыкли пользователи современных мессенджеров.

По мнению разработчиков, Matrix является оптимальной заменой IRC, так как такие альтернативы как Telegram, Slack и Discord централизованы и построены на основе проприетарных разработок, что не соответствует требованиям проекта. Matrix является открытым проектом, использует открытые стандарты и уделяет большое внимание обеспечению безопасности и приватности пользователей.

Matrix обеспечивает оконечное (end-to-end) шифрование на базе проверенного алгоритма Signal, поддерживает поиск и неограниченный просмотр истории переписки, может использоваться для передачи файлов, отправки уведомлений, оценки присутствия разработчика в online, организации телеконференций, совершения голосовых и видео звонков. Поддерживаются также такие расширенные возможности как уведомление о наборе текста, подтверждение прочтения, push-уведомления и поиск на стороне сервера, синхронизация истории и состояния клиентов, различные варианты идентификаторов (email, номер телефона, учётная запись в Facebook и т.п.).

Для пользователей и разработчиков введены в строй новые Matrix-чаты #kde-welcome:kde.org (для ознакомления новичков), #kde:kde.org (общий чат для пользователей), #kde-devel:kde.org (чат для разработчиков) и #kde-chat:kde.org (общение на произвольные темы). Все ранее существующие каналы IRC и Telegram будут сохранены, но в качестве основной платформы теперь преподносится Matrix. Для работы могут использоваться любые клиенты, поддерживающие протокол Matrix, такие как Riot (доступен для Web, Android, iOS, Linux, Windows и macOS), Weechat (CLI на Lua), nheko (С++/Qt), Quaternion (С++/Qt) и Fractal (Rust/GTK).

Источник: [ссылка]

Раскрыты детали уязвимости в WordPress 5.0.0

Саймон Скэннелл (Simon Scannell), в прошлом году предложивший метод атаки «PHP Phar deserialization«, опубликовал сведения об уязвимости в системе управления контентом WordPress, позволяющей выполнить произвольный код на сервере, имея привилегии автора публикаций (Author) на сайте. В обновлениях WordPress 4.9.9 и 5.0.1 была добавлена частичная защита, позволяющая блокировать атаку в основном коде WordPress, но полностью проблема остаётся не исправленной и в актуальном выпуске WordPress 5.0.3 может быть эксплуатирована через дополнительные ошибки в плагинах (отмечается, что проблема проявляется в некоторых популярных плагинах c миллионами активных установок).

Уязвимость стала следствием двух проблем — возможности переопределения метаданных в БД и ошибки при обработке файловых путей. Первая проблема позволяет переопределить в БД значение записи с параметрами изображения в таблице wp_postmeta. При изменении параметров загруженного изображения (например, описания), передаваемые данные обрабатываются в виде массива параметров, что позволяет переопределить и значение служебного параметра «_wp_attached_file», содержащего имя файла с изображением.

Так как, параметр из БД с именем файла используется относительно каталога «wp-content/uploads» без повторной проверки корректности имени, атакующий может через добавление символов «../» выйти за пределы базового каталога с загружаемыми файлами. В функции wp_crop_image(), вызываемой при кадрировании изображения, поддерживается как обработка уже загруженного локального файла, так и загрузка внешнего файла. Если локальный файл присутствует, обрабатывается он, а если нет то предпринимается попытка его загрузки c внешнего хоста (например, если указан файл evil.jpg и его нет в локальной ФС, он будет загружен как «https://targetserver.com/wp-content/uploads/evil.jpg»).

После кадрирования файл сохраняется в отдельном каталоге с добавлением к имени приставки «cropped-» («cropped-evil.jpg»). Изменив при помощи вышеотмеченной проблемы имя на «evil.jpg?/../../evil.jpg» можно сохранить результирующее изображение в любом каталоге, например, в каталоге с темами оформления (wp-content/themes), PHP-файлы из которого могут быть выполнены через вызов функции include() при подключении тем. Имя выполняемого файла с темой определяется в переменной «_wp_page_template», которая по аналогии с именем изображения может быть изменена на произвольное значение. Таким образом, на данном этапе атакующий уже может добиться записи изображения в каталог с текущей темой оформления и указать этот файл в качестве текущего шаблона оформления.

Для решения задачи по передаче PHP-кода под видом изображения используется особенность PHP-расширения Imagick, которое после редактирования оставляет содержимое метаданных EXIF в неизменном виде, т.е. в результирующем изображении остаются те же параметры EXIF, что и в исходном. Разместив вместо блока EXIF PHP-код можно добиться его выполнения при попытке подключения шаблона определённой темы оформления. При применении для преобразования изображений PHP-расширения GD, атака усложняется, так как GD очищает EXIF и для выполнения кода необходим особый подбор значений пикселей, который после обработки в GD образует PHP-код.

Интересно, что в ходе изучения внутренних структур PHP-расширения в libgd параллельно была выявлена уязвимость CVE-2019-69772, приводящая к переполнению буфера при разборе в функции gdImageColorMatch специально оформленных изображений, которую также можно использовать для атаки на PHP-приложения, вызывающие функцию imagecolormatch().

Источник: [ссылка]

0.77% крупнейших сайтов используют Canvas для скрытой идентификации посетителей

Французский исследователь безопасности Антуан Вастель (Antoine Vastel) опубликовал результаты анализа распространённости метода скрытой идентификации («browser fingerprinting»), учитывающего особенности отрисовки графики при помощи HTML-элемента canvas. Изучение 500 тысяч самых популярных сайтов по рейтингу Alexa показало, что указанная техника скрытой идентификации применяется на 3825 (0.77%) главных страницах сайтов. Интересно, что похожее исследование, проведённое в 2016 году и охватившее миллион крупнейших сайтов, выявило применение canvas для скрытой идентификации на 1.6% сайтах.

Расхождение результатов исследований объясняется снижением охвата проверяемых сайтов (на менее популярных сайтах более активно используются спорные техники идентификации) и различными методами анализа (исследование коснулось только главных страниц, в то время как код для идентификации мог размещаться только на страницах входа). Всего выявлено 69 различных видов идентификационных картинок, при этом 17 из них встречаются только на одном сайте, а два самых распространённых canvas, изображённые ниже, на 1241 и 900 сайтах соответственно.

Техника идентификации пользователя при помощи Canvas реализуется через скрытую отрисовку картинки на странице, которая затем анализируется на предмет особенностей вывода, специфичных для используемого графического стека, GPU и видеодрайвера. В невидимом iframe отрисовывается изображение и текст, после чего сформированная картинка читается при помощи getImageData и генерируется хэш загруженных данных, который выступает идентификатором. Метод идентификации на основе Canvas получил распространение благодаря появлению свободной библиотеки fingerprintjs2, которая также может учитывать для генерации идентификатора такие параметры, как разрешение экрана, специфичные HTTP-заголовки, списки установленных плагинов и шрифтов, активность определённых Web API, учёт особенностей WebGL и т.п.

Источник: [ссылка]

Выпуск программы для управления фотографиями digiKam 6.0

Спустя 10 месяцев с момента прошлого выпуска опубликован релиз программы для управления коллекцией фотографий digiKam 6.0.0, который вобрал в себя новые возможности, подготовленные студентами в рамках программы Google Summer of Code.

Основные новшества:

  • Предложены полноценные средства для управления видеофайлами, по аналогии с ранее доступными инструментами для управления коллекцией фотографий. Видео можно просматривать прямо в интерфейсе digiKam, не вызывая отдельный проигрыватель. Для обработки различных форматов и кодеков задействован пакет FFmpeg;
  • В LightTable, редактор изображений и Showfoto интегрированы все доступные инструменты для импорта и экспорта данных в различные web-сервисы (раннее инструменты импорта и экспорта были доступны только в интерфейсе для работы с альбомом);
  • В движок декодирования изображений в raw-формате добавлена поддержка новых камер, в том числе камер Phone 8, iPhone 8 plus, iPhone X, Canon PowerShot A410/A540, G1 X Mark III, G9 X Mark II, EOS 6D Mark II, Huawei P9, Honor6a, Honor9, Mate10, Nikon Coolpix B700, Samsung Galaxy Nexus, Galaxy S3, S6 (SM-G920F), S7, S7 Edge, S8 и т.п.
  • Обеспечено сохранение данных о похожести изображений в отдельном файле;
  • Упрощён процесс аутентификации в web-сервисах при помощи протокола OAuth. Добавлена поддержка протокола OAuth2 и предложен новый интерфейс авторизации;
  • Добавлены новые инструменты для экспорта данных в web-сервисы Pinterest, OneDrive и Box;
  • Реализована возможность раздельной группировки содержимого альбома на основании свойств каждого элемента. Например, новая возможность позволяет разделить содержимое альбома на виртуальные подальбомы, с разделением по форматам изображения, месяцам снимков и т.п.
  • Добавлена поддержка ручной перегруппировки в режиме просмотра миниатюр (icon-view). Пиктограмму теперь можно свободно переместить на другое место в списке и позиция будет запомнена между перезапусками программы;
  • Код обработки метаданных EXIV адаптирован для использования нового выпуска библиотеки Exiv2 0.27;
  • В режимах AlbumView, ImageEditor, LightTable и Showfoto возвращён инструмент корректировки времени снимков (TimeAdjust), позволяющий быстро поменять время для большого числа файлов не прибегая к использованию менеджера пакетных операций (Batch Queue Manager);
  • Повышена стабильность работы версии digiKam для платформы Windows. Добавлен инструмент DrMinGW для быстрой отправки отчётов о проблемах;
  • Проведён большой рефакторинг кода, нацеленный на сокращение внешних зависимостей и упрощение сопровождения пакета;
  • Закрыто 633 отчёта об ошибках.

Источник: [ссылка]

Оценка производительности браузерных дополнений для блокировки рекламы

Рассмотрев критику изменений в третьей редакции манифеста Chrome, нарушающих работу многих дополнений для блокирования нежелательного контента и обеспечения безопасности, разработчики из компании Google подытожили свою позицию по данному вопросу. Утверждается, что в реализации нового API declarativeNetRequest будут учтены пожелания и замечания авторов дополнений, в том числе будет расширен лимит на число правил блокировки, реализована возможность динамического добавления/удаления правил, добавлена поддержка дополнительных условий фильтрации и возможность не только блокирования, но и изменения частей запроса (например, для чистки отдельных Cookie).

Тем не менее, как и раньше разработчики Chrome намерены ограничить старый API webRequest режимом только для чтения (неблокирующим режимом), что позволит только отслеживать запросы, но не даст изменять их. Отсутствие блокирующего режима в API webRequest потребует перевода блокировщиков рекламы на новый API declarativeNetRequest, который самостоятельно применяет предоставленные дополнением правила фильтрации (предлагается встроенный в браузер типовой движок фильтрации запросов).

В качестве одного из основных аргументов против API webRequest представители Google называют замедление отображения контента, так как данный API работает в блокирующем режиме и перед выводом страницы браузер ожидает полного завершения обработки данных дополнением. Авторы сервиса WhoTracks.Me и разработчики блокировщика рекламы Ghostery решили проверить насколько данные заявления соответствуют действительности и провели тестирование производительности фильтрации контента дополнениями uBlock Origin, Adblock Plus, Brave, DuckDuckGo и Cliqz/Ghostery.

Для проведения теста была организована симуляция обработки большого числа запросов при помощи рассматриваемых дополнений, для чего с использованием Node.js были подготовлены тесты, прогоняющие через движки блокировщиков 250 тысяч запросов (случайные страницы 500 самых популярных сайтов), 19% из которых приводили к блокировке. В блокировщиках использовался набор правил Easylist, включающий 38978 записей.

Измерение показало, что все рассмотренные блокировщики работают очень эффективно — задержки при применении фильтров, блокирующие вывод на этапе использования API webRequest, пренебрежимо малы на общем фоне. В среднем применение блокировщика замедляет выполнение запроса лишь на доли миллисекунд, что никак не может рассматриваться как повод для отключения поддержки блокирующего режима работы API webRequest.

В общем зачёте наибольшие задержки были зафиксированы для дополнения DuckDuckGo, которое замедляло каждый запрос в среднем на 8 мс. Для Ghostery, uBlock Origin, Adblock Plus и Brave задержки в среднем составили 0.007 мс, 0.017 мс, 0.019 мс и 0.041 мс соответственно. Разница обработки запросов подлежащих и не подлежащих блокировке оказалась минимальной: Ghostery (0.007/0.006 мс), uBlock Origin (0.016/0.018 мс), Adblock Plus (0.014/0.020 мс), Brave (0.062/ 0.038 мс) и DuckDuckGo (8.31/6.78 мс).

Дополнительно была измерена производительность кода для кэширования (сериализации и десериализации) внутреннего представления данных, применяемого для ускорения загрузки базы правил. Данные операции приводят лишь к задержкам на этапе запуска и не влияют на производительность работы дополнения. Размер кэша c сериализированной базой правил для всех дополнений составляет примерно 2 Мб.

При сравнении потребления памяти наибольшую эффективность продемонстрировали дополнения Ghostery и uBlock Origin, требующие для работы 2-3 Мб ОЗУ. Потребление памяти Adblock Plus и DuckDuckGo составило приблизительно 15-16 Мб.

При измерении времени на разбор списка правил блокировки из общей массы выделился блокировщик браузера Brave, который потратил на разбор в 20 раз больше времени, чем остальные блокировщики. Наиболее быстрыми в этом тесте оказались Adblock Plus и uBlock Origin.

Источник: [ссылка]

Уязвимость в systemd, которую можно использовать для блокирования работы системы

В systemd найдена уязвимость (CVE-2019-6454), позволяющая вызвать крах управляющего процесса инициализации (PID1) через отправку непривилегированным пользователем специально оформленного сообщения через шину D-Bus. Разработчики из Red Hat также не исключают возможность применения уязвимости для организации выполнения кода с привилегиями root, но окончательно возможность такой атаки пока не определена.

Манипулируя размером отправляемого через D-Bus сообщения атакующий может сместить указатель за границы выделенной для стека памяти, обойдя защиту «stack guard-page», суть которой в подстановке на границе со стеком страниц памяти, обращение к которым приводит к генерации исключения (page-fault). По мнению исследователя безопасности, выявившего уязвимость, смещение указателя стека возможно только на неиспользуемые страницы памяти (unmapped), что не позволяет организовать выполнение кода в контексте процесса PID1, но даёт возможность атакующему инициировать крах PID1 с последующим переходом ядра Linux в состояние «panic» (в случае краха обработчика PID 1, происходит крах всей системы).

В systemd устанавливается обработчик сигналов, пытающийся перехватить крахи процесса PID1 (segmentation fault) и запускающий shell для восстановления. Но так как в ходе атаки обращение производится к неотражённым страницам памяти (unmapped), ядро не может вызвать данный обработчик сигнала и просто завершает процесс с PID 1, что, в свою очередь, приводит к невозможности продолжения дальнейшей работы и переходу в состояние «panic», требующего перезапуска системы.

Обновления пакетов с устранением уязвимости опубликованы для SUSE/openSUSE, Fedora, Ubuntu и частично для Debian (только для Debian Stretch). Проблема остаётся неисправленной в RHEL. Успешная атака продемонстрирована в Ubuntu 18.10 с systemd 239 и в CentOS 7.6 с systemd 219. В качестве обходного пути защиты может использоваться сборка в GCC c включением опции «-fstack-clash-protection», которая по умолчанию применяется в Fedora 28 и 29.

Следует отметить, что в 2014 году автор системной библиотеки musl выделял среди основных архитектурных проблем systemd излишнюю раздутость обработчика PID1 и ставил под сомнение целесообразность реализации обработчика DBus API на уровне PID1, так как он является серьёзным вектором для проведения атак и может негативно влиять на надёжность всей системы.

Источник: [ссылка]