| · | 23.07.2021 | Ошибка в обновлении Chrome OS привела к невозможности входа в систему (123 +16) |
|
Компания Google выпустила обновление Chrome OS 91.0.4472.165, в котором была допущена ошибка, приведшая к невозможности входа в систему после перезагрузки. Некоторые пользователи столкнулись с зацикливанием во время загрузки, в результате которого экран входа в систему не появлялся, а если появлялся, то не позволял подключиться под своей учётной записью. По горячим следам выпущено исправление Chrome OS 91.0.4472.167 с устранением проблемы.
Пользователям, которые уже установили первое обновление, но ещё не перезагрузили устройство (обновление активируется после перезагрузки), рекомендуется срочно довести свою систему до версии 91.0.4472.167. В случае если проблемное обновление установлено и вход блокирован, рекомендуется оставить устройство на некоторое время включённым и дождаться пока автоматически загрузится новое обновление. В качестве запасного варианта можно попытаться принудительно инициировать обновление через гостевой вход. Пользователям система которых зависает не доходя до экрана входа и автоматическая установка нового обновления не срабатывает, рекомендовано нажать комбинацию Ctrl + Alt + Shift + R два раза и воспользоваться режимом сброса к заводским настройкам (Powerwash) или функцией отката системы до прошлой версии через USB (Revert), но в обоих режимах локальные данные пользователя удаляются. Если вызвать режим Powerwash не удаётся потребуется перевод устройства в режим разработчика с выполнением сброса в исходное состояние. Один из пользователей проанализировал исправление и пришёл к выводу, что причина блокировки входа в опечатке, из-за которой в условном операторе, применяемом для проверки типа ключей, был пропущен один символ "&". Вместо
if (key_data.has_value() && !key_data->label().empty()) {
было указано
if (key_data.has_value() & !key_data->label().empty()) {
Оператор "&" отличается от "&&" тем, что "&&" позволяет пропускать вычисление второго аргумента, если в первом получен ложный результат. В случае оператора "&", компилятор должен вычислить обязательно и первый аргумент, и второй аргумент, но если первый "key_data.has_value()" вернёт "false", то вызов оператора "->" во втором аргументе приведёт к неопределённому поведению, потому что "label" не инициализирован (key_data имеет тип Optional<T>, схожий с optional<T> из стандарта на C++, и с Maybe/Option в Haskell/Rust). Такого бы не случилось, если бы использовался оператор "&&", потому что он вычисляет аргументы слева направо и прерывает вычисления, если первый оказался "false".
| ||
|
Обсуждение (123 +16) |
Тип: К сведению |
| ||
| · | 23.07.2021 | Выпуск firewalld 1.0 (103 +6) |
|
Представлен релиз динамически управляемого межсетевого экрана firewalld 1.0, реализованного в форме обвязки над пакетными фильтрами nftables и iptables. Firewalld запускается в виде фонового процесса, позволяющего динамически изменять правила пакетного фильтра через D-Bus, без необходимости перезагрузки правил пакетного фильтра и без разрыва установленных соединений. Проект уже применяется во многих дистрибутивах Linux, включая RHEL 7+, Fedora 18+ и SUSE/openSUSE 15+. Код firewalld написан на языке Python и распространяется под лицензией GPLv2.
Для управления межсетевым экраном используется утилита firewall-cmd, которая при создании правил отталкивается не от IP-адресов, сетевых интерфейсов и номеров портов, а от названий служб (например, для открытия доступа к SSH нужно выполнить "firewall-cmd --add --service=ssh", для закрытия SSH - "firewall-cmd --remove --service=ssh"). Для изменения конфигурации межсетевого экрана также может использоваться графический интерфейс firewall-config (GTK) и апплет firewall-applet (Qt). Поддержка управления межсетевым экраном через D-BUS API firewalld имеется в таких проектах, как NetworkManager, libvirt, podman, docker и fail2ban. Значительное изменение номера версии связано с внесением изменений, нарушающих обратную совместимость и меняющих поведение работы с зонами. Все определённые в зоне параметры фильтрации теперь применяются только для трафика, адресованного хосту, на котором запущен firewalld, а для фильтрации транзитного трафика требуется настройка политик. Наиболее заметные изменения:
| ||
|
Обсуждение (103 +6) |
Тип: Программы |
| ||
| · | 22.07.2021 | Доступна GUI-библиотека SixtyFPS 0.1.0, развиваемая бывшими разработчиками Qt (117 +29) |
|
Опубликован выпуск кросс-платформенной библиотеки для создания графических интерфейсов SixtyFPS 0.1.0, ориентированной для применения на встроенных устройствах и в десктоп приложениях на платформах Linux, macOS и Windows, а также для использования в веб браузерах (WebAssembly). Код библиотеки написан на языке Rust и распространяется под лицензией GPLv3 или коммерческой лицензией, допускающей использование в проприетарных продуктах без открытия кода.
Авторы библиотеки (Olivier Goffart и Simon Hausmann) бывшие разработчики KDE, позже перешедшие в компанию Trolltech для работы над Qt, сейчас основали свою компанию, развивающую SixtyFPS. Одной из целей проекта является предоставление возможности работы с минимальным потреблением ресурсов CPU и памяти (для работы необходимо несколько сотен килобайт ОЗУ). Для отрисовки доступно два бэкенда - gl на базе OpenGL ES 2.0 и qt, использующий Qt QStyle. Поддерживается создание интерфейсов в программах на языках Rust, C++, и JavaScript. Авторами библиотеки разработан специальный язык разметки ".60", который компилируется в нативный для выбранной платформы код. Существует возможность протестировать язык в онлайн редактор или ознакомиться с примерами, собрав их самостоятельно.  Пример кода .60:
HelloWorld := Window {
width: 400px;
height: 400px;
Text {
y: parent.width / 2;
x: parent.x + 200px;
text: "Hello, world";
color: blue;
}
}
Примеры интерфейса:  
| ||
| · | 22.07.2021 | Проект CentOS создал группу для развития решений для автомобильных систем (86 –19) |
|
Управляющий совет проекта CentOS одобрил формирование SIG-группы (Special Interest Group) Automotive, которая рассматривается как нейтральная площадка для развития проектов, связанных с адаптацией Red Hat Enterprise Linux для автомобильных информационных систем и для организации взаимодействия с профильными проектами, такими, как AGL (Automotive Grade Linux).
Среди целей новой SIG-группы упоминается как создание нового открытого ПО для автомобильных систем, так и использование уже существующих upstream-проектов. В итоге планируется наладить сборку и поддержание специализированного варианта CentOS для автомобильных информационных систем, созданного на основе продукта RHEL for Edge. Работа будет вестись в тесном сотрудничестве с рабочей группой Fedora IoT и с использованием некоторых уже созданных в Fedora наработок, подготовленных для встраиваемых систем. Отмечается, что автомобильные информационные системы находятся на пороге эволюционного скачка, связанного с переходом от использования набора изолированных встраиваемых систем (ECU, Electronic Control Unit), подключённых через шину CAN, к применению концепции граничных вычислений (edge computing). Предполагается, что наблюдаемый сдвиг парадигмы даёт возможность решениям на базе Linux возглавить превращение автомобильных информационных систем в умное edge-устройство, а созданная группа станет площадкой для совместной работы по созданию Linux-решений, соответствующих новой парадигме.
| ||
|
Обсуждение (86 –19) |
Тип: К сведению |
| ||
| · | 21.07.2021 | Релиз Chrome 92 (107 –20) |
|
Компания Google представила релиз web-браузера Chrome 92. Одновременно доступен стабильный выпуск свободного проекта Chromium, выступающего основой Chrome. Браузер Chrome отличается использованием логотипов Google, наличием системы отправки уведомлений в случае краха, модулями для воспроизведения защищённого видеоконтента (DRM), системой автоматической установки обновлений и передачей при поиске RLZ-параметров. Следующий выпуск Chrome 93 запланирован на 31 августа.
Основные изменения в Chrome 92:
Кроме нововведений и исправления ошибок в новой версии устранено 35 уязвимостей. Многие из уязвимостей выявлены в результате автоматизированного тестирования инструментами AddressSanitizer, MemorySanitizer, Control Flow Integrity, LibFuzzer и AFL. Критических проблем, которые позволяют обойти все уровни защиты браузера и выполнить код в системе за пределами sandbox-окружения, не выявлено. В рамках программы по выплате денежного вознаграждения за обнаружение уязвимостей для текущего релиза компания Google выплатила 24 премий на сумму 112000 долларов США (две премии $15000, четыре премии $10000, одна премия $8500, две премии $7500, три премии $5000, одна премия $3000 и одна премия $500). Размер 11 вознаграждений пока не определён.
| ||
|
Обсуждение (107 –20) |
Тип: Программы |
| ||
| · | 21.07.2021 | Root-уязвимость в ядре Linux и отказ в обслуживании в systemd (232 +56) |
|
Исследователи безопасности из компании Qualys раскрыли детали двух уязвимостей, затрагивающих ядро Linux и системный менеджер systemd. Уязвимость в ядре (CVE-2021-33909) позволяет локальному пользователю добиться выполнения кода с правами root через манипуляции с каталогами большой вложенности.
Опасность уязвимости усугубляется тем, что исследователям удалось подготовить рабочие эксплоиты, работающие в Ubuntu 20.04/20.10/21.04, Debian 11 и Fedora 34 в конфигурации по умолчанию. Отмечается, что другие дистрибутивы не проверялись, но теоретически тоже подвержены проблеме и могут быть атакованы. Полный код эксплоитов обещают опубликовать после повсеместного устранения проблемы, а пока доступен лишь ограниченный в функциональности прототип, вызывающий крах системы. Проблема проявляется с июля 2014 года и затрагивает выпуски ядра начиная с 3.16. Исправление уязвимости было скоординировано с сообществом и принято в состав ядра 19 июля. Основные дистрибутивы уже сформировали обновления пакетов с ядром (Debian, Ubuntu, Fedora, RHEL, SUSE, Arch). Уязвимость вызвана отсутствием проверки результата преобразования типа size_t в int перед выполнением операций в коде seq_file, осуществляющем создание файлов из последовательности записей. Отсутствие проверки может привести к записи в область вне границ буфера при создании, монтировании и удалении структуры каталогов с очень большим уровнем вложенности (размер пути более 1 ГБ). В итоге атакующий может добиться записи 10-байтовой строки "//deleted" со смещением "- 2 ГБ - 10 байт", указывающим на область, непосредственно предшествующую выделенному буферу. Подготовленный эксплоит требует для работы 5 ГБ памяти и 1 миллион свободных inode. Работа эксплоита сводится к созданию через вызов mkdir() иерархии из около миллиона вложенных каталогов для достижения размера файлового пути, превышающего 1 ГБ. Данный каталог монтируется через bind-mount в отдельном пространстве имён идентификаторов пользователей (user namespace), после чего запускается функция rmdir() для его удаления. Параллельно создаётся поток, загружающий небольшую eBPF-программу, который блокируется на стадии после проверки псевдокода eBPF, но до его JIT-компиляции. В непривилегированном пространстве имён идентификаторов пользователей открывается файл /proc/self/mountinfo и начинается чтение длинного пути каталога, примонтированного при помощи bind-mount, что приводит к записи строки "//deleted" в область до начала буфера. Позиция для записи строки выбирается таким образом, что она перезаписывает инструкцию в уже проверенной, но ещё не скомпилированной программе eBPF. Далее на уровне программы eBPF неконтролируемая запись вне буфера трансформируется в управляемую возможность чтения и записи в другие структуры ядра через манипуляцию со структурами btf и map_push_elem. Затем эксплоит определяет местоположение буфера modprobe_path[] в памяти ядра и перезаписывает в нём путь "/sbin/modprobe", что позволяет инициировать запуск любого исполняемого файла с правами root в случае выполнения вызова request_module(), который выполняется, например, при создании сокета netlink. Исследователями приводится несколько обходных методов защиты, которые эффективны только для конкретного эксплоита, но не устраняют саму проблему. Рекомендуется установить параметр "/proc/sys/kernel/unprivileged_userns_clone" в значение 0 для запрета монтирования каталогов в отдельном пространстве имён идентификаторов пользователей, а также "/proc/sys/kernel/unprivileged_bpf_disabled" в 1 для запрета загрузки программ eBPF в ядро.
Примечательно, что, разбирая альтернативный вариант атаки, связанный с использованием механизма FUSE вместо bind-mount для монтирования большого каталога, исследователи натолкнулись на ещё одну уязвимость (CVE-2021-33910), затрагивающую системный менеджер systemd. Оказалось, что при попытке монтирования через FUSE каталога c размером пути, превышающим 8 МБ, в управляющем процессе инициализации (PID1) наступает исчерпание памяти стека и крах, который приводит систему в состояние "panic". Проблема связана с тем, что systemd отслеживает и разбирает содержимое /proc/self/mountinfo и обрабатывает каждую точку монтирования в функции unit_name_path_escape(), в которой выполняется операция strdupa(), размещающая данные в стеке, а не в динамически выделяемой памяти. Так как максимальный размер стека ограничен через RLIMIT_STACK, обработка слишком большого пути к точке монтирования приводит к краху процесса PID1 и остановке работы системы. Для атаки можно использовать простейший модуль FUSE в сочетании с использованием в качестве точки монтирования каталога с большим уровнем вложенности, размер пути в котором превышает 8 МБ. Проблема проявляется начиная с systemd 220 (апрель 2015), уже устранена в основном репозитории systemd и исправлена в дистрибутивах (Debian, Ubuntu, Fedora, RHEL, SUSE, Arch). Примечательно, что в выпуске systemd 248 эксплоит не работает из-за ошибки в коде systemd, приводящей к сбою при обработке /proc/self/mountinfo. Также интересно, что в 2018 году возникла похожая ситуация и при попытке написать эксплоит к уязвимости CVE-2018-14634 в ядре Linux, исследователи Qualys натолкнулись на три критические уязвимости в systemd.
| ||
|
Обсуждение (232 +56) |
Тип: Проблемы безопасности |
Интересно
| ||
| · | 20.07.2021 | Проект Stockfish подал иск против компании ChessBase и отозвал лицензию GPL (64 +65) |
|
Проект Stockfish, распространяемый под лицензией GPLv3, подал в суд на компанию ChessBase, отозвав у той лицензию GPL на использование своего кода. Stockfish представляет собой сильнейший из шахматных движков, использующихся на шахматных сервисах lichess.org и chess.com. Иск подан в связи с включением кода Stockfish в проприетарный продукт без открытия исходных текстов производной работы.
Компания ChessBase известна своей шахматной программой Fritz с 1990-х годов. В 2019 году она выпустила движок Fat Fritz, основанный на нейросети открытого движка Leela Chess Zero, в своё время основанного на наработках проекта AlphaZero, открытого Google. Это не являлось нарушением какого-либо законодательства, хотя разработчики Leela были недовольны тем, что ChessBase позиционировала Fat Fritz как самостоятельную разработку, не признавая заслуг команд AlphaZero и LeelaZero. В 2020 году компания ChessBase выпустила продукт Fat Fritz 2.0, основанный на движке Stockfish 12, имеющем собственную архитектуру нейронной сети NNUE (ƎUИИ, Efficiently Updatable Neural Networks). Команда Stockfish при помощи юристов смогла добиться отзыва из торговых сетей DVD с программой Fat Fritz 2.0 в Германии, но, не удовлетворённая результатом, заявила об отзыве лицензии GPL на Stockfish у ChessBase, и подала иск в суд. Это не первый сезон драмы вокруг кода Stockfish, который коммерческие движки заимствуют с игнорированием GPL. Например, ранее случился казус с утечкой исходных текстов проприетарного движка Houdini 6, по которым стало ясно, что он основан на коде Stockfish. Houdini 5 участвовал в соревновании TCEC и добрался до суперфинала девятого сезона, но в конечном итоге уступил Stockfish'у. В 2017 году следующая версия Houdini 6 смогла выиграть у Komodo суперфинал TCEC десятого сезона. Исходные тексты, утёкшие в 2020 году, раскрыли этот нечестивый обман, попирающий один из краеугольных камней FOSS - GPL. Напомним, что лицензия GPL предусматривает возможность отзыва лицензии у нарушителя и прекращения всех прав лицензиата, предоставленных ему данной лицензией. В соответствии с принятыми в GPLv3 правилами расторжения лицензии, если нарушения были выявлены впервые и устранены за 30 дней с момента уведомления, права на лицензию восстанавливаются, и лицензия полностью не отзывается (договор остаётся не нарушен). Права возвращаются сразу также в случае устранения нарушений, если правообладатель не уведомил о нарушении в течение 60 дней. Если сроки истекли, то нарушение лицензии можно трактовать как нарушение договора, за которое у суда можно добиться финансовых взысканий.
| ||
| · | 20.07.2021 | Muse Group добивается закрытия репозитория проекта musescore-downloader на GitHub (188 –23) |
|
Компания Muse Group, основанная проектом Ultimate Guitar и владеющая открытыми проектами MusesCore и Audacity, возобновила попытки закрытия репозитория musescore-downloader, в котором развивается приложение для бесплатной загрузки музыкальных нот с сервиса musescore.com без необходимости входа на сайт и без подключения к платной подписке Musescore Pro. Претензии также касаются репозитория musescore-dataset с коллекцией нот, скопированных с musescore.com. При этом Muse Group не имеет ничего против проекта LibreScore, в котором тот же автор развивает свободную альтернативу musescore.com, основанную на кодовой базе приложения MuseScore, распространяемого под лицензией GPL.
Представители Muse Group попросили автора добровольно удалить репозитории musescore-downloader и musescore-dataset. Первый репозиторий содержит приложение, позволяющее через обращение к внутреннему API загружать бесплатно любой контент с сервиса musescore.com. Репозиторий подлежит закрытию так как в musescore-downloader осуществляется неправомерный обход систем защиты авторских прав (против доступа к общедоступному содержимому musescore.com претензий нет). Через второй репозиторий, musescore-dataset, незаконно распространяются копии работ, лицензированных у музыкальных издателей. В случае musescore-dataset проблемы более серьёзные и могут рассматриваться как уголовное преступление (умышленное нарушение авторских прав с преступным умыслом). Автор проблемных репозиториев отказался удалять репозитории и компания Muse Group столкнулась с непростой дилеммой. С одной стороны имеется угроза прекращения существование сервиса musescore.com, а с другой возможность искалечить жизнь человека. Простейшим выходом было бы привлечение юристов и отправка официального DMCA-требования в GitHub на блокировку репозиториев, но Muse Group решили не прибегать к таким действиям, а договориться неофициальным путём, после того как выяснили, что Wenzheng Tang, разработчик проблемных репозиториев, уехал из Китая по политическим причинам и в случае проблем с законом его ждёт аннулирование вида на жительство и депортация с последующим преследованием на родине за оскорбление китайского правительства. На другой чаше весов находится вероятность нарушения статуса кво, которого удалось достигнуть с музыкальными издателями. Изначально весь контент размещался в MuseScore добровольцами бесплатно и без ограничения доступа, но потом началось преследование сообщества правообладателями и создатели MuseScore потратили много сил чтобы удержаться на плаву и сохранить сайт. Проблема в том, что права на транскрипцию музыкального произведения в ноты и аранжировку принадлежит правообладателю, независимо от того, кто выполнил транскрипцию или аранжировку. Ценой продолжения работы MuseScore.com стало лицензирование музыкальных нот популярных произведений, права на которые принадлежат таким компаниям, как Alfred, EMI и Sony, и ограничение доступа с введением системы платной подписки. Компания Muse Group по закону обязана обеспечить соблюдение авторских прав на лицензированные музыкальные произведения, а наличие лазейки для неограниченной загрузки лицензированного содержимого создаёт угрозу существованию сервиса. Противостояние с автором musescore-downloader продолжается с февраля 2020 года. Отмечается, что время на раздумья уже почти исчерпано и скоро предстоит принять решение. Действия против нарушителя также в любой момент могут быть предприняты напрямую со стороны правообладателей. Позиция автора musescore-downloader сводится к тому, что он использовал в своей программе штатный публично документированный API, информация о котором была удалена с сайта musescore.com уже после создания приложения. Кроме того, автор musescore-downloader считает неправильным, что доступ к публикациям, подготовленным энтузиастами и изначально размещённым в открытом доступе безвозмездно, был ограничен только для платных подписчиков, в то время как Muse Group не является владельцем прав на контент, подготовленный пользователями (пользователи не владеют правами на ноты чужих произведений, так как правообладателем являются музыканты и музыкальные издатели).
| ||
|
Обсуждение (188 –23) |
Тип: К сведению |
| ||
| · | 19.07.2021 | Линус Торвальдс прокомментировал ситуацию с драйвером NTFS от Paragon Software (266 +113) |
|
При обсуждении вопроса разделения полномочий при сопровождении кода файловых систем и связанных с VFS драйверов, Линус Торвальдс выразил готовность напрямую принять патчи с новой реализацией файловой системы NTFS, если компания Paragon Software возьмёт на себя обязанности мэйнтенера файловой системы NTFS в ядре Linux и получит подтверждение от других разработчиков ядра, выполнивших рецензирование корректности кода (судя по всему, подтверждения уже имеются).
Линус отметил, что среди разработчиков VFS ядра нет людей, отвечающих за приём pull-запросов с новыми ФС, поэтому подобные запросы можно отправлять лично ему. В целом Линус намекнул, что он не видит особых проблем с принятием в основной состав ядра нового кода NTFS, так как плачевное состояние старого драйвера NTFS не выдерживает критики, а к новому драйверу Paragon за год не было предъявлено существенных претензий. За год в списке рассылки linux-fsdevel для рецензирования было предложено 26 версий патчей ntfs3, в которых были устранены высказанные замечания, но вопрос включения в состав ядра застопорился в невозможности найти мэйнтейнера VFS, который мог бы принять решение по концептуальным вопросам - что делать со старым драйвером ntfs и реализовывать ли в новом драйвере устаревшие вызовы FAT ioctl. В текущем виде для принятия патчей необходимо обеспечить в ntfs3 совместимость с недавно внесёнными изменениями в API iov, из-за которых патч перестал собираться, и по возможности перевести код на использование fs/iomap (предполагается, что это не критично и адаптация может быть выполнена уже при нахождении ntfs3 в ядре). Код нового драйвера NTFS был открыт компанией Paragon Software в августе прошлого года и отличается от уже имеющегося в ядре драйвера возможностью работы в режиме записи. Драйвер поддерживает все возможности актуальной версии NTFS 3.1, включая расширенные атрибуты файлов, режим сжатия данных, эффективную работу с пустотами в файлах и воспроизведение изменений из журнала для восстановления целостности после сбоев.
| ||
|
Обсуждение (266 +113) |
Тип: К сведению |
| ||
| · | 17.07.2021 | Уязвимость в cdnjs, позволившая выполнить код на серверах Cloudflare (184 +32) |
|
В предоставляемой компанией Cloudflare сети доставки контента cdnjs, предназначенной для ускорения доставки JavaScript-библиотек, выявлена критическая уязвимость, позволяющая выполнить произвольный код на серверах CDN. Опасность проблемы усугубляется тем, что для загрузки JavaScript-библиотек сервисом пользуется около 12.7% всех сайтов в интернете и компрометация инфраструктуры позволяет подменить библиотеки, отдаваемые любым из этих сайтов.
Сервис cdnjs осуществляет загрузку пакетов из Git или репозитория NPM, после чего даёт возможность любому сайту бесплатно воспользоваться сетью доставки контента Cloudflare для ускорения загрузки JavaScript-библиотек. При изучении кода компонентов cdnjs, опубликованных на GitHub, было выявлено, что для распаковки NPM-пакетов в архивах tgz используется штатный модуль archive/tar на языке Go, которые выдаёт список файлов как есть, без нормализации путей. В случае, когда скрипт распаковывает содержимое на основании выданного списка, наличие в архиве файлов вида "../../../../../../../tmp/test" может привести к перезаписи произвольных файлов в системе, насколько это позволяют права доступа. Было предположено, что атакующий может подать заявку на добавление своей библиотеки в cdnjs и загрузить в репозиторий NPM специально оформленный архив, содержащий файлы с символами "../" в пути. На серверах cdnjs периодически выполняется операция "autoupdate", в ходе которой обработчик загружает новые версии предложенной библиотеки и распаковывает содержимое. При помощи файлов c путями "../" атакующий может добиться перезаписи файлов со скриптами сервиса и выполнения своего кода на сервере на котором производилась распаковка. В случае загрузки обновлений из Git было выяснено, что загружающий обновления обработчик не учитывал символические ссылки при копировании файлов из Git. Данная особенность позволяла организовать чтение любых файлов с сервера через добавление в Git символических ссылок. Эксперименты с демонстрацией взлома cdnjs для получения премии на HackerOne было решено начать с проверки гипотезы относительно чтения файлов. В Git-репозиторий отдаваемой через CDN JavaScript-библитеки была добавлена символическая ссылка test.js, указывающая на файл /proc/self/maps. После публикации новой версии библиотеки обработчик обновлений обработал данный репозиторий и опубликовал указанный файл в cdnjs (test.js был создан как символическая ссылка и при запросе данного файла выдавалось содержимое /proc/self/maps). Подставив символическую ссылку на файл /proc/self/environ автор исследования заметил, что внутри отданных данных присутствуют значения переменных окружения GITHUB_REPO_API_KEY и WORKERS_KV_API_TOKEN. В первой переменной хранился ключ к API для доступа с правом записи в репозиторий robocdnjs на GitHub. Во второй переменной хранился токен к хранилищу KV в cdnjs. Воспользовавшись полученными сведениями злоумышленник мог внести изменения в cdnjs и полностью скомпрометировать инфраструктуру.
| ||
|
Обсуждение (184 +32) |
Тип: Проблемы безопасности |
| ||
| · | 16.07.2021 | Уязвимость в uBlock Origin, приводящая к краху или исчерпанию ресурсов (163 +33) |
|
В системе блокирования нежелательного контента uBlock Origin выявлена уязвимость, позволяющая добиться краха или исчерпания памяти при навигации по специально оформленному URL, в случае подпадания данного URL под фильтры строгой блокировки ("strict blocking"). Уязвимость проявляется только при прямом переходе на проблемный URL, например при клике по ссылке.
Уязвимость устранена в обновлении uBlock Origin 1.36.2. Аналогичной проблеме также подвержено дополнение uMatrix, но его сопровождение прекращено и обновления больше не выпускаются. Обходные пути защиты в uMatrix отсутствуют (изначально предлагалось отключить все фильтры строгой блокировки через вкладку "Assets", но эта рекомендация была признана недостаточной и создающей проблемы для пользователей с собственными правилами блокировки). В ηMatrix, форке uMatrix от проекта Pale Moon, уязвимость устранена в выпуске 4.4.9. Фильтр строгой блокировки обычно определяется на уровне доменов и подразумевает запрет любых соединений, даже при прямом переходе по ссылке. Уязвимость вызвана тем, что во время перехода на страницу, подпадающую под фильтр строгой блокировки, пользователю отображается предупреждение, в котором приводятся сведения о заблокированном ресурсе, в том числе показывается URL и параметры запроса. Проблема в том, что uBlock Origin разбирает параметры запроса рекурсивно и добавляет в дерево DOM без учёта уровня вложенности. При обработке специально оформленного URL в uBlock Origin для Chrome можно вызвать крах процесса, в котором выполняется браузерное дополнение. После краха, до тех пор пока процесс с дополнением не перезапустится, пользователь остаётся без блокировки нежелательного содержимого. В Firefox наблюдается исчерпание памяти.  Дополнение: В NoScript некоторые пользователи отмечают наличие ошибки, приводящей при открытии некоторых сайтов к 100% загрузке CPU в Firefox.
| ||
|
Обсуждение (163 +33) |
Тип: Проблемы безопасности |
| ||
| · | 16.07.2021 | Проект Pine64 выпустил водонепроницаемые умные часы PineTime (222 +29) |
|
Сообщество Pine64, занимающееся созданием открытых устройств, выпустило в продажу умные часы PineTime, поставляемые в герметичном корпусе, выдерживающем погружение на глубину 1 метр. Стоимость устройства $26.99. В отличие от ранее доступного комплекта для разработчиков, предложенный вариант часов не укомплектован низкоуровневым отладочным интерфейсом и ориентирован на обычного потребителя (эксперименты с установкой непроверенных прошивок не рекомендуются из-за ограниченных возможностей по восстановлению после сбоев прошивки).
Часы PineTime построены на микроконтроллере NRF52832 MCU (64 MHz) и оснащены 512KB системной Flash-памяти, 4 MB Flash для данных пользователя, 64KB ОЗУ, 1.3-дюймовым сенсорным экраном с разрешением 240x240 пикселей (IPS, 65K цветов), Bluetooth 5, акселерометром (используется как шагомер), датчиком пульса и вибромотором. Заряда аккумулятора (180 mAh) хватает на 3-5 дней автономной работы. Вес - 38 грамм.  Поступившее в продажу устройство PineTime поставляется с новым выпуском прошивки InfiniTime 1.2. Из изменений в новом выпуске отмечается включение в состав приложения "метроном", улучшение работы приложения "таймер", проведение работы по сокращению потребления оперативной и постоянной памяти. Размер прошивки уменьшился с 420KB до 340KB.   В предоставляемой по умолчанию прошивке InfiniTime используется операционная система реального времени FreeRTOS 10, графическая библиотека LittleVGL 7 и Bluetooth-стек NimBLE 1.3.0. Загрузчик прошивки основан на MCUBoot. Прошивка может обновляться через OTA-обновления, передаваемые со смартфона через Bluetooth LE. Код пользовательского интерфейса написан на C++ и включает такие возможности как часы (цифровые, аналоговые), фитнес-трекер (пульсометр и шагомер), показ уведомлений о событиях на смартфоне, фонарик, управление воспроизведением музыки на смартфоне, отображение инструкций от навигатора, секундомер и две простые игры (Paddle и 2048). Через настройки можно определять время выключения дисплея, формат времени, условия пробуждения, менять яркость экрана, оценивать заряд аккумулятора и версию прошивки. На смартфоне и компьютере для управления часами могут использоваться приложения Gadgetbridge (для Android), Amazfish (для Sailfish и Linux) и Siglo (для Linux). Имеется экспериментальная поддержка WebBLEWatch, web-приложения для синхронизации часов из браузеров, поддерживающих API Web Bluetooth. Кроме того, для PineTime энтузиастами подготовлена новая альтернативная прошивка Malila, основанная на RIOT OS, снабжённая интерфейсом в стиле GNOME (шрифт Cantarell, пиктограммы и стиль GNOME) и поддерживающая MicroPython. Кроме InfiniTime и Malila для PineTime также развиваются прошивки на основе платформ Zephyr, Mynewt OS, MbedOS, TinyGo, WaspOS (на базе Micropython) и PinetimeLite (расширенная модификация прошивки InfiniTime). Из новостей проекта Pine64 также можно отметить реализацию для смартфона PinePhone поддержки аппаратного ускорения воспроизведения видео в Gstreamer средствами VPU, доступного в SoC Allwinner A64. PinePhone теперь способен выводить видео с качеством 1080p и 30fps, что может быть полезно для просмотра видео при подключении PinePhone к внешнему экрану. Из других изменений упоминается подготовка образа с прошивкой на базе Arch Linux ARM и оболочки KDE Plasma Mobile 5.22. До версии 21.06 обновлены прошивки на основе postmarketOS, предлагаемые в вариантах с оболочками Phosh, KDE Plasma Mobile и SXMO.
| ||
|
Обсуждение (222 +29) |
Тип: К сведению |
| ||
| · | 15.07.2021 | Компания Valve анонсировала игровую консоль Steam Deck на базе Arch Linux (361 +101) |
|
Компания Valve представила многофункциональный портативный игровой компьютер Steam Deck, поставляемый с операционной системой SteamOS 3, особенностью которой стал переход с Debian на пакетную базу Arch Linux. Пользователю предоставлена возможность как запуска клиента Steam с переделанной домашней страницей, так и открытия рабочего стола KDE Plasma для выполнения любых приложений Linux.
Консоль оснащена SoC на базе 4-ядерного CPU Zen 2 (2.4-3.5 ГГц, 448 GFlops FP32) и GPU с 8 вычислительными блоками RDNA 2 (1.6 TFlops FP32), разработанном для Valve компанией AMD. В Steam Deck также имеется 7-дюймовый сенсорный экран (1280x800, 60 Гц), 16 GB ОЗУ, Wi-Fi 802.11a/b/g/n/ac, Bluetooth 5.0, USB-C с DisplayPort 1.4 и microSD. Размер - 298x117x49 мм, вес - 669 гр. Заявлено от 2 до 8 часов автономной работы от аккумулятора (40Whr). Консоль поступит в продажу в декабре 2021 года по цене 399 долларов с 64 GB eMMC PCIe, $529 с 256GB NVMe SSD и $649 c 512GB NVMe SSD. Дополнение: Заявлена опциональная официальная док-станция с портами:
Доставка Steam Deck начнётся в декабре 2021 года в США, Канаде, ЕС и Великобритании. В 2022 году список регионов обещают расширить. 
| ||
|
Обсуждение (361 +101) |
Тип: К сведению |
| ||
| · | 15.07.2021 | В Chrome 94 появится режим HTTPS-First (87 –3) |
|
Компания Google объявила о решении добавить в Chrome 94 режим HTTPS-First, который напоминает ранее появившийся в Firefox 83 режим HTTPS Only. При попытке открытия ресурса без шифрования по HTTP браузер вначале попытается обратиться к сайту HTTPS и если попытка окажется неудачной пользователю будет показано предупреждение об отсутствии поддержки HTTPS и предложение открыть сайт без шифрования. В Chrome 94 новый режим будет доступен в качестве отдельно включаемой опции, но в будущем Google рассматривает возможность активации HTTPS-First по умолчанию для всех пользователей (аналогичные планы по включению HTTPS Only по умолчанию в Firefox имеются и у Mozilla).
По статистике Google в настоящее время более 90% запросов в Chrome выполняются с использованием HTTPS. Ожидается, что добавление HTTPS-First позволит улучшить данный показатель. В долгосрочной перспективе поддержка HTTP в Chrome будет сохранена, но Google планирует добавить вывод дополнительных предупреждений, информирующих пользователей об угрозах, возникающих при обращении к сайтам без шифрования, а также ограничить доступ к некоторым возможностям web-платформы для страниц, открытых по HTTP. Одновременно объявлено о решении провести в Chrome 93 эксперимент по замене индикатора защищённого соединения (замок в адресной строке) на более нейтральный и не вызывающий двойной трактовки символ (например, "V"), нажатие на который приводит к открытию диалога с параметрами страницы. Для соединений, установленных без шифрования, продолжит показываться индикатор "не защищено". В качестве причины замены индикатора упоминается то, что многие пользователи ассоциируют индикатор замка с тем, что содержимому сайта можно доверять, а не воспринимают его как признак шифрования соединения. Cудя по опросу Google лишь 11% процентов пользователей понимают смысл пиктограммы с замком. 
| ||
|
Обсуждение (87 –3) |
Тип: К сведению |
| ||
| · | 15.07.2021 | Уязвимость в подсистеме ядра Linux Netfilter (104 +22) |
|
В Netfilter, подсистеме ядра Linux, используемой для фильтрации и модификации сетевых пакетов, выявлена уязвимость (CVE-2021-22555), позволяющая локальному пользователю получить привилегии root в системе, в том числе находясь в изолированном контейнере. Для тестирования подготовлен рабочий прототип эксплоита, обходящий механизмы защиты KASLR, SMAP и SMEP. Исследователь, выявивший уязвимость, получил от Google вознаграждение, размером 20 тысяч долларов, за выявление метода обхода изоляции контейнеров Kubernetes в кластере kCTF.
Проблема проявляется начиная с ядра 2.6.19, выпущенного 15 лет назад, и вызвана ошибкой в обработчиках IPT_SO_SET_REPLACE и IP6T_SO_SET_REPLACE, приводящей к переполнению буфера при отправке специально оформленных параметров через вызов setsockopt в режиме compat. В обычных условиях вызов compat_setsockopt() может выполнить только пользователь root, но необходимые для совершения атаки полномочия также могут быть получены непривилегированным пользователем в системах с включённой поддержкой пространств имён идентификаторов пользователей (user namespaces). Пользователь может создать контейнер с отдельным пользователем root и из него эксплуатировать уязвимость. Например, "user namespaces" по умолчанию включён в Ubuntu и Fedora, но не активирован в Debian и RHEL. Патч с исправлением уязвимости принят в состав ядра Linux 13 апреля. Обновления пакетов уже сформированы проектами Debian, Arch Linux и Fedora. В Ubuntu, RHEL и SUSE обновления на стадии подготовки. Проблема возникает в функции xt_compat_target_from_user() из-за некорректного расчёта размера памяти при сохранении структур ядра после преобразования из 32- в 64-разрядное представление. Ошибка позволяет записать четыре нулевых байта в любую позицию за границей выделенного буфера, ограниченную смещением 0x4C. Указанной возможности оказалось достаточно для создания эксплоита, позволяющего добиться получения прав root - через очистку указателя m_list->next в структуре msg_msg создавались условия для обращения к данным после освобождения памяти (use-after-free), что затем использовалось для получения сведений об адресах и изменения других структур через манипуляцию с системным вызовом msgsnd().
| ||
|
Обсуждение (104 +22) |
Тип: Проблемы безопасности |
| ||
| Следующая страница (раньше) >> | ||
