The OpenNET Project / Index page

[ новости/++ | форум | wiki | теги ]

28.06.2017 Леннарт Поттеринг представил mkosi, инструмент для генерации образов ОС (18 –7)
  Следом за Casync Леннарт Поттеринг (Lennart Poettering) представил ещё один свой проект - mkosi (Make Operating System Image), в рамках которого подготовлен инструментарий для генерации загрузочных образов операционных систем. Проект написан на языке Python, распространяется под лицензией LGPL 2.1 и представляет собой обвязку над такими утилитами, как dnf (режим "--installroot"), debootstrap, pacstrap и zypper, предоставляющую унифицированный интерфейс для создания образов, независимый от используемого дистрибутива.

Mkosi позиционируется как legacy-free, т.е. поддерживает только актуальные в современных реалиях технологии. Например, образы могут генерироваться только с таблицами разделов GPT (MBR не поддерживает), только на основе systemd и только для загрузки на системах с EFI (системы с BIOS не поддерживаются). Для корневого раздела могут применяться ФС ext4, btrfs и squashfs. Дополнительно в образ могут включаться раздел подкачки, /srv и /home. Для данных в разделах может быть включено шифрование через LUKS, верификация целостности при помощи dm-verity и проверка по цифровой подписи для UEFI SecureBoot. Также возможна генерация системного образа в виде каталога в текущей ФС (OS tree), tar-архива или подразделов Btrfs.

Поддерживается создание образов на базе дистрибутивов Fedora, Debian, Ubuntu, Arch Linux и openSUSE. В качестве хост-системы для сборки образов может применяться любой дистрибутив, в котором может выполняться debootstrap (Debian), dnf (Fedora ), pacstrap (Arch) или zypper (openSUSE). Для ускорения повторных сборок может применяться кэш пакетов RPM и DEB. Созданный образ может быть запущен в виде контейнера командой "systemd-nspawn -bi image.raw". Системная начинка определяется через файл конфигурации mkosi.default, в котором можно выбрать тип дистрибутива для построения образа и список устанавливаемых пакетов.

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

Подготовленный образ может быть запущен напрямую на оборудовании, использован внутри виртуальной машины, запущен как контейнер при помощи systemd-nspawn или вызыван как сервис systemd (unit с "RootImage="). Для разработчиков встраиваемой техники mkosi даёт возможность легко организовать генерацию системных образов прошивки, защищённых от модификации посторонними лицами, благодаря применению dm-verity и UEFI SecureBoot.

  1. OpenNews: Леннарт Поттеринг представил свой новый проект Casync
  2. OpenNews: Разработчики Systemd намерены внедрить кардинально новые методы построения дистрибутивов Linux
  3. OpenNews: Docker и CoreOS объединили усилия в разработке единого формата контейнеров
Обсуждение (18 –7) | Тип: Программы |
28.06.2017 Компания Sony открыла свои наработки в области нейронных сетей (8 +9)
  Компания Sony представила проект NNabla (Neural Network Libraries), в рамках которого открыла наработки в области построения нейронных сетей для решения задач глубинного машинного обучения. Система универсальная и изначально рассчитана на использование как на настольных ПК и встраиваемых устройствах, так и в кластерах и крупных серверах для решения исследовательских задач и практического применения. Код ядра NNabla написан на языке C++ и распространяется под лицензией Apache 2.0.

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

Поддерживается работа в Linux и Windows. Благодаря ядру на C++ система достаточно компактна и может работать на встраиваемых системах с ограниченными ресурсами. Для ускорения вычислений предоставлены средства для организации выполнения с привлечением специфичных реализаций, например на базе FPGA. Из готовых оптимизирующих модулей отмечается бэкенд для задействования CUDA для выноса вычислений на сторону GPU. Также поддерживается специальный движок для оптимизации работы с памятью, позволяющий организовать совместное использование памяти.

Из областей, в которых Sony уже применяет NNabla, отмечены оценка стоимости недвижимости в Sony Real Estate Corporation, распознавание действий пользователя в системе "Xperia Ear" (например, подтверждение операции или приём звонка кивком головы) и распознавание рукописного ввода в электронной книге Sony DPT-RP1. По своему назначению NNabla близок к такими существующим фреймворкам, как TensorFlow, Torch и Theano.

  1. OpenNews: Выпуск системы машинного обучения TensorFlow 1.0 и классификатора изображений ResNeXt
  2. OpenNews: Первый выпуск Gneural Network, программируемой нейронной сети от проекта GNU
  3. OpenNews: Проект OpenNMT развивает систему машинного перевода на основе нейронной сети
  4. OpenNews: Анонсировано открытие кода платформы искусственного интеллекта DeepMind Lab
  5. OpenNews: Baidu открыл наработки в области машинного обучения
Обсуждение (8 +9) | Тип: К сведению |
27.06.2017 Более половины npm-пакетов могли быть скомпрометированы из-за ненадёжных паролей доступа (98 +24)
  Никита Сковорода, входящий в управляющий технический комитет проекта Node.js, опубликовал результаты анализа надёжности паролей для доступа к учётным записям в репозитории NPM. Результат оказался более чем печальным - в ходе проверки удалось получить доступ к 12% аккаунтов (13% пакетов) из-за использования в них предсказуемых и тривиальных паролей, таких как "123456". Среди подобных учётных записей есть и популярные модули, которые находятся в зависимостях у других пакетов. С учётом загрузки других модулей по цепочке зависимостей, компрометация ненадёжных учётных записей может поразить в сумме до 52% от всех модулей в NPM.

Всего удалось получить доступ к 15495 учётным записям, используемым для управления 66876 пакетами. В том числе был получен доступ к 4 учётным записям пользователей из Top20 самых популярных пакетов. Также был получен контроль над 13 пользователями, пакеты которых загружают более 50 млн раз в месяц, 40 пользователями с более 10 млн загрузок в месяц и 282 с более 1 млн загрузок в месяц. Компания NPM Inc приняла исследование во внимание и инициировала процесс смены паролей для ненадёжных учётных записей. Для усиления защиты NPM запрещено использование словарных и коротких паролей, скоро будет ограничена поддержка "HTTP Basic auth", в более отдалённых планах внедрение двухфакторной аутентификации.

Контроль над 2545 учётными записями (5470 пакетов) был получен в ходе проведения Bruteforce-атаки по подбору типовых паролей. Данные об 12150 учётных записях (57112 пакетов) были получены путём сопоставления сведений из крупных публичных утечек баз паролей (когда пользователь использовал идентичные пароли на NPM и взломанных сайтах, базы паролей которых были выложены в открытый доступ). Допуск к 732 учётным записям (4786 пакетов) удалось получить путём варьирования пароля из публичных утечек (например, добавление цифр, замена имени на npm и т.п.). Контроль над оставшимися 120 проблемными учётными записями (582 пакета) был получен через поиск утечек параметров входа в файлах, опубликованных на GitHub (например, вместе с другими файлами загружены .npmrc, config.json, .gitconfig и т.п.).

Некоторые интересные факты:

  • В учётной записи для доступа к модулю koa, который в прошлом месяце был загружен 300 тысяч раз, использовался пароль "password";
  • Один из пользователей, контролирующий более 20 млн загрузок в месяц, в ответ на отзыв скомпрометированного пароля, установил в качестве нового пароля содержимое старого, добавив к нему символ "!";
  • Пользователь, входящий в top-20, после сброса скомпрометированного пароля опять вернул свой старый пароль через некоторое время;
  • У 662 пользователей был установлен пароль "123456", у 168 - "123", у 115 - "password";
  • 1409 пользователей (1%) указали в качестве пароля свой логин;
  • 10% пользователей повторно использовали свой заведомо скомпрометированный пароль: 9.7% в изначальном виде, а 0.6% внеся в него незначительное изменение;
  • Трафик всех пакетов, к которым был получен доступ в ходе исследования, составляет почти два миллиарда (1 946 302 172) загрузок в месяц, что примерно 20% от общего объёма загрузок.

  1. OpenNews: Небезопасное хранение данных в менеджерах паролей для платформы Android
  2. OpenNews: Применение тайпсквоттинга для распространения вредоносных модулей NPM, PyPI и Gems
  3. OpenNews: Незащищённость NPM к атакам по внедрению вредоносных модулей-червей
  4. OpenNews: Инцидент с захватом прав на NPM-модуль привёл к сбою в работе проектов, использующих NPM
  5. OpenNews: В RubyGems устранена уязвимость, позволявшая подменять файлы в репозитории
Обсуждение (98 +24) | Тип: Проблемы безопасности |
27.06.2017 Разработчик языка XL опубликовал новую сборочную систему build (23 +9)
  Christophe de Dinechin, автор языка программирования XL, участник разработки спецификаций C++, создатель системы виртуализации для HP-UX и разработчик ряда известных компьютерных игр, в настоящее время работающий в компании Red Hat над технологией удалённого рабочего стола SPICE, опубликовал новую сборочную систему "build". Сборочная система ранее была задействована для сборки кодовой базы проектов ELFE и XL, а теперь может применяться в качестве универсального продукта, не привязанного к конкретным системам. Код открыт под лицензией GPLv3.

Build представляет собой серию надстроек над утилитой make для упрощения сборки проектов на С/С++, которая оформлена в виде набора make-сценариев. Ключевой особенностью Build является предоставление встроенных средств для автоматической настройки сборочного окружения, которые в отличие от Automake не требуют запуска отдельной фазы генерации сборочных файлов. Build также поддерживает ведение сборочного лога, подсветку вывода, обработку стадий тестирования и установки приложения. Отмечается, что Build не так богат возможностями как Autoconf, но вполне подходит для несложных проектов. При этом Build очень прост в использовании и не требует написания длинных make-файлов или определения правил для automake и cmake.

Особенности Build:

  • Очень короткие и хорошо читаемые сборочные сценарии, предоставляющие все наиболее полезные возможности сборочной системы;
  • Компактный размер: для типовой сборки достаточно поставки кода makefile, размером около 500 строк;
  • Высокая скорость работы, так как короткие makefile с небольшим числом правил разбираются очень быстро;
  • Автоматическая инкрементальная конфигурация проекта, генерация файла config.h;
  • Автоматическое ведение лога с деталями процесса сборки;
  • Автоматическая однопроходная генерация зависимостей для заголовочных файлов;
  • Поддержка команд "make test" и "make install";
  • Компактный отчёт о ходе сборки с подсветкой важных элементов;
  • Вывод после завершения сборки сводного отчёта об ошибках и предупреждениях;
  • Подсветка ошибок и предупреждений в выводе;
  • Правила для сборки в различных режимах (оптимизация, отладка, формирование релиза, профилирование);
  • Наличие правил-модификаторов для типовых сборочных опций, таких как v-debug для подробной отладки;
  • Возможность определения персональных настроек через переменные окружения;
  • Встроенная система подсказки ("make help");
  • Полная поддержка стандартного синтаксиса Makefile и всех возможностей утилиты make;
  • Поддержка распараллеливания процесса сборки на несколько потоков;
  • Возможность разделения библиотек для ускорения сборки (библиотеки собираются только при первой сборке или при инициировании глубокой сборки);
  • Хорошая переносимость. Система протестирована в Linux, macOS и Windows.

Пример сборочного сценария:


    BUILD=./
    SOURCES=hello.cpp
    PRODUCTS=hello.exe
    CONFIG= ‹stdio.h› ‹iostream› clearenv libm
    TESTS=product
    include $(BUILD)rules.mk 

  1. OpenNews: Первый публичный выпуск сборочного инструментария build2
  2. OpenNews: Компания Google представила первый выпуск открытой системы сборки Bazel
  3. OpenNews: Twitter представил первый значительный выпуск системы сборки Pants
  4. OpenNews: Выпуск сборочного инструментария qbs 1.8, развиваемого проектом Qt
  5. OpenNews: Для GNOME-приложений представлена новая экспериментальная система сборки BuilDj
Обсуждение (23 +9) | Тип: Программы |
26.06.2017 Выпуск рабочего стола Lumina 1.3 (44 +12)
  Сформирован релиз легковесного окружения рабочего стола Lumina 1.3, развиваемого проектом TrueOS (бывший PC-BSD). Компоненты окружения написаны с использованием библиотеки Qt5 (без применения QML). Lumina придерживается классического подхода к организации пользовательского окружения. В состав входит рабочий стол, панель приложений, менеджер сеансов, меню приложений, система настройки параметров окружения, менеджер задач, системный лоток, система виртуальных рабочих столов. Код проекта написан на языке C++ и распространяется под лицензией BSD. Новый выпуск Lumina распространяется через систему портов FreeBSD и репозиторий TrueOS.

В качестве оконного менеджера применяется Fluxbox, но в одном из следующих значительных выпусков планируется заменить его на оконный менеджер собственной разработки. В рамках проекта также развивается собственный файловый менеджер Insight, обладающий такими возможностями как поддержка вкладок для одновременной работы с несколькими директориями, накопление ссылок на избранные директории в разделе закладок, наличие встроенного мультимедиа-проигрывателя и просмотрщика фотографий с поддержкой слайдшоу, средствами для управления снапшотами ZFS, поддержкой подключения внешних плагинов-обработчиков.

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

  • В состав включён и задействован по умолчанию новый набор пиктограмм в стиле Material Design, доступный как в светлом, так и в тёмном представлениях. Ранее предлагаемый набор пиктограмм oxygen, заимствованный из проекта KDE, может быть установлен в качестве опции;
  • Представлено новое приложение Lumina Media Player, предоставляющее средства для воспроизведения музыки и видео с локального диска, а также для прослушивания интернет-радио (пока поддерживается только сервис Pandora). Интерфейс отличается минимализмом и ориентирован на быстрое создание списка воспроизведения и работу в фоне, не отвлекая пользователя (сворачивается в системный лоток и отображает изменение состояния на пиктограмме). Для воспроизведения контента задействован Qt-класс QMediaPlayer и Gstreamer;
  • Обновлено оформление файлового менеджера Insight, в котором добавлен режим древовидной навигации по всем каталогам в системе. В новой версии также проведена оптимизация производительности, обеспечено кэширование пиктограмм и реализована полная интеграция с менеджером архивов lumina-archiver;
  • Добавлена новая утилита lumina-xdg-entry, предназначенная для упрощения создания ярлыков и файлов .desktop.
  • Обеспечена возможность размещения папок на рабочем столе и навигации по их содержимому непосредственно с рабочего стола;
  • Добавлены средства для автоматического переноса настроек монитора от других пользовательских окружений (пока поддерживаются только одномониторные конфигурации);
  • Проведена оптимизация методов работы с пиктограммами на рабочем столе и взаимодействия с системой;
  • В текстовом редакторе lumina-texteditor добавлена возможность использования файлов-манифестов в формате JSON для определения правил подсветки синтаксиса. Число поддерживаемых форматов файлов расширено до 10. Добавлена возможность привязки настроек к отдельным типам файлов, таких как выбор метода разбивки слов, ограничение числа символов в строке, параметры выбора шрифтов и число отступов для табуляции. Добавлена опция для отображения диалога с обзором несохранённых изменений перед выходом.
  • В инструменте для создания скриншотов модернизирован интерфейс, добавлена возможность выбора области экрана для скриншота и обеспечен показ предупреждения о выходе без сохранения изображения;
  • Продолжена работа по обеспечению комфортной работы на мониторах с высокой плотностью пикселей (high-DPI);
  • По умолчанию отключен композитный менеджер Compton (может быть активирован вручную);
  • Добавлена поддержка дистрибутива Slackware;
  • Началась работа над системой вывода уведомлений lumina-notify, функциональность которой ещё не доведена до должного вида;
  • Утилиты Lumina, работа над которыми ещё не завершена, перемещены к каталог "experimental";
  • Порт для FreeBSD разделён на 12 частей: x11/lumina (общий метапорт для установки всех компонентов), x11/lumina-core (базовый рабочий стол), x11/lumina-coreutils (основные утилиты, такие как lumina-config, lumina-xconfig, lumina-search) и развиваемые проектом приложения (например, deskutils/lumina-fm, deskutils/lumina-mediaplayer, deskutils/lumina-calculator и т.п.);

  1. OpenNews: Третья стабильная сборка проекта TrueOS, пришедшего на смену PC-BSD
  2. OpenNews: Вторая стабильная сборка проекта TrueOS, пришедшего на смену PC-BSD
  3. OpenNews: Выпуск рабочего стола Lumina 1.2
  4. OpenNews: Выпуск рабочего стола Lumina 1.1
  5. OpenNews: Первый стабильный выпуск рабочего стола Lumina
Обсуждение (44 +12) | Тип: Программы |
25.06.2017 Проект Debian уведомил о проблемах с CPU Intel Skylake и Kaby Lake (176 +34)
  Разработчики дистрибутива Debian предупредили о выявлении проблем с работой режима Hyper-threading в процессорах Intel, построенных на базе микроархитектур "Skylake" и "Kaby Lake", которые выражаются в непредсказуемом поведении системы (например, крах приложения или повреждение данных). Проблема проявляется в 6 и 7 поколении процессоров Intel Core для настольных, встраиваемых и мобильных систем, в серверных процессорах Xeon 5 и Xeon 6, а также в некоторых моделях, выпускаемых под брендом Intel Pentium.

Проблема выявлена разработчиками инструментария OCaml, которые столкнулись с крахами при работе компилятора OCaml, собранного при помощи GCC. Первые упоминания проблемы отслеживаются со второго квартала 2016 года, но из-за трудоёмкости диагностики причина выявлена только сейчас. В ходе разбирательства стало ясно, что проблема проявляется только на некоторых процессорах Intel со включенным режимом Hyper-threading. Дальнейшее исследование условий возникновения крахов показало, что проблема вызвана некорректной обработкой определённой последовательности инструкций и является дефектом процессоров Intel Skylake и Kaby Lake.

В частности, проблема проявляется, когда выполняются короткие циклы, включающие менее 64 машинных инструкций, использующих регистры AH, BH, CH или DH, а также их более длинные варианты (RAX, EAX и AX для AH, RBX, EBX и BX для BH и т.п.), при условии, что активны оба логических процессора на том же физическом процессоре. Разработчики связались с компанией Intel, но не получили вразумительного ответа, при этом спустя несколько месяцев в списке изменений в очередном обновлении микрокода от Intel было замечено упоминание исправления, которое решало проблему в OCaml. После этого разработчики OCaml связались с сопровождающими пакет intel-microcode в Debian и поделились своей информацией.

Пользователям Debian c процессорами Intel Skylake (model в /proc/cpuinfo = 78 или 94 и stepping = 3) рекомендуется как можно скорее установить пакет intel-microcode с обновлением микрокода (версия 3.20170511.1), доступный в репозитории non-free для веток unstable, testing, Debian 9 "stretch" и Debian 8 (jessie-backports). Для остальных моделей Intel Skylake и CPU Kaby Lake исправление через intel-microcode пока недоступно, поэтому им рекомендуется отключить режим работы Hyper-threading в BIOS/UEFI или установить обновление прошивки BIOS/UEFI от производителя оборудования, если оно уже выпущено (Intel erratа SKW144, SKL150, SKX150, SKZ7, KBL095, KBW095). Проблема не специфична для Debian и Linux, и проявляется в любых других ОС.

Для определения подвержена ли система проблеме следует выполнить "grep name /proc/cpuinfo | sort -u" и сверить модель процессора со списками кодовых номеров процессоров Skylake и Kaby-Lake, а также проверить наличие поддержки Hyper-threading (флаг "ht" в /proc/cpuinfo).


   $ grep -E 'model|stepping' /proc/cpuinfo | sort -u
   model	: 26
   model name	: Intel(R) Xeon(R) CPU           E5530  @ 2.40GHz
   stepping	: 5

   $  grep -q '^flags.*[[:space:]]ht[[:space:]]' /proc/cpuinfo && echo "Hyper-threading is supported"
   Hyper-threading is supported

  1. OpenNews: Intel устранил удалённую уязвимость в технологии AMT (Active Management Technology)
  2. OpenNews: Выявлен метод обхода защиты ASLR на процессорах Intel
  3. OpenNews: Проблемы с управлением питанием процессоров Intel Skylake в Linux
  4. OpenNews: Процессоры Intel Skylake и Broxton потребуют наличия несвободных бинарных прошивок
  5. OpenNews: CoreBoot не сможет работать с новыми чипами Haswell и Broadwell от Intel
Обсуждение (176 +34) | Тип: Тема для размышления |
25.06.2017 В OpenBSD добавлена новая защита от атак на основе заимствования кусков кода (16 +13)
  В состав OpenBSD принят набор патчей с реализацией технологии Trapsleds, позволяющей усложнить выполнение эксплоитов, использующих технику заимствования кусков кода, основанную на приёмах возвратно-ориентированного программирования (ROP, Return-Oriented Programming).

Суть добавленного в OpenBSD метода защиты в применении для заполнения добавочных областей (используются для выравнивания блоков с кодом функций по 16-байтовой границе) инструкций INT3 вместо NOP на системах с архитектурой AMD64. Любые последовательности NOP длиннее двух байт заменяются на двухбайтовый короткий переход JMP поверх набора инструкций INT3, используемых для заполнения. Таким образом, при штатном выполнении программа перепрыгнет набор инструкций INT3 вместо холостого выполнения серии инструкций NOP.

В случае осуществления атаки, при переходе на код гаджета (составляющий эксплоит блок заимствованных машинных инструкций) попадание на область заполнения на базе INT3 вместо NOP приведёт к возникновению исключения и остановке выполнения (SIGTRAP) атакованной программы. При вызове гаджета создатели эксплоита должны будут точно рассчитать адрес перехода, что значительно труднее, чем организовать переход на предшествующую гаджету область заполнения из NOP-инструкций. Разница в производительности при использовании JMP-перехода при проведении синтетических тестов почти не заметна и составляет менее 1%, что может рассматриваться как погрешность измерения.

Напомним, что техника заимствования кусков кода используется для эксплуатации переполнений буфера в условиях, когда в страницах памяти стека и буфера установлен запрет на исполнение кода. Для организации выполнения кода атакующего в таких условиях логика выполнения shell-кода формируется с использованием методов возвратно-ориентированного программирования (ROP) - атакующий не пытается разместить свой код в памяти, а оперирует уже имеющимися в загруженных библиотеках кусками машинных инструкций, завершающихся инструкцией возврата управления (как правило, это окончания библиотечных функций). Работа эксплоита сводится к построению цепочки вызовов подобных блоков ("гаджетов") для получения нужной функциональности. Для автоматизации выявления гаджетов применяются специальные инструменты. Используя готовые блоки машинных инструкций (гаджеты) можно организовать достаточно сложные операции, в том числе организовать работу условных операторов и циклов.

  1. OpenNews: Проект grsecurity представил защиту от атак с использованием заимствования кусков кода
  2. OpenNews: Разработчики OpenBSD подготовили для libc механизм защиты anti-ROP
  3. OpenNews: Для OpenBSD представлена новая техника рандомизации адресного пространства ядра
  4. OpenNews: Выпуск OpenBSD 6.0
  5. OpenNews: Проект grsecurity опубликовал реализацию механизма защиты RAP для ядра Linux
Обсуждение (16 +13) | Тип: К сведению |
24.06.2017 Опубликована 49 редакция списка самых высокопроизводительных суперкомпьютеров (57 +14)
  Опубликован 49-й выпуск рейтинга 500 самых высокопроизводительных компьютеров мира. В десятке самых мощных кластеров отмечается только одно изменение: кластер Piz Daint, развиваемый в швейцарском национальном суперкомпьютерном центре, был модернизирован и переместился с 8 на 3 место. Кластер построен на платформе Cray XC50, в ходе обновления он был укомплектован акселераторами на базе GPU NVIDIA Tesla P100, что позволило удвоить его суммарную производительность в тестах Linpack (с 9.8 до 19.6 петафлопс).

Занимавший ранее третье место кластер Titan, построенный в Национальной лаборатории Оук-Ридж (министерство энергетики США) на базе платформы Cray XK7, переместился на четвёртое место, показав производительность в 17.6 петафлопс. Рейтинг возглавляет китайский кластер Sunway TaihuLight, работающий в национальном суперкомпьютерном центре Китая и демонстрирующий производительность в 93 петафлопс, что в три раза больше показателей занимающего второе место китайского кластера Tianhe-2, показавшего производительность в 33.9 петафлопс.

Отмечается, что во второй раз за 24-летнию историю рейтинга наблюдается ситуация, когда среди трёх лидеров отсутствуют кластеры из США. Ранее подобная ситуация наблюдалась лишь в ноябре 1996 года, когда первые три места заняли японские кластеры. При этом США продолжает принадлежать 5 из 10 самых крупных кластеров и 168 из всех систем, отмеченных в рейтинге (число систем в Китае снизилось со 171 до 160).

Наиболее интересные тенденции:

  • Самый мощный отечественный кластер Lomonosov 2 сместился с 52 на 59 место в рейтинге. Кластер Lomonosov опустился со 132 на 164 место. Третий по производительности отечественный кластер Tornado опустился с 226 на 297 место. Всего в рейтинге осталось только 3 отечественных кластера (в прошлом рейтинге было 5 отечественных систем, а пять лет назад - 12);
  • Со 171 до 160 уменьшилось число систем в Китае. Число систем в США снизилось со 171 до 168, тем не менее этого оказалось достаточно, чтобы вернуть себе звание лидера по числу кластеров в рейтинге. Примечательно, что всего два года назад в Китае было 37 кластеров, входящих в TOP500;
  • Распределение по количеству суперкомпьютеров в разных странах:
    • США: 168 (171 в прошлой редакции рейтинга);
    • Китай: 160 (171)
    • Япония: 33 (27);
    • Германия: 28 (31);
    • Франция: 18 (20)
    • Великобритания: 17 (13)
    • Южная корея 8 (4)
    • Италия: 8 (6);
    • Польша 6 (7);
    • Канада 6 (1);
    • Россия c 3 кластерами не вошла в десятку лидеров;
  • Распределение по операционным системам, используемым на суперкомпьютерах. По сравнению с прошлой редакцией рейтинга раскладка осталась неизменной:

    • Linux - 498 систем, 99.6%
    • Unix - 2, 0.4%
    • Смешанные - 0, 0%
    • Windows - 0, 0%
    • BSD - 0, 0%
  • Из Linuх-систем (в скобках указано значение из прошлой редакции рейтинга):
    • 58.8% (64.2%) не детализируют дистрибутив,
    • 16.6% (12.6%) используют CentOS,
    • 8.6% (8.6%) - Cray Linux,
    • 4.2% (5%) - SUSE,
    • 3.4% (3%) - RHEL,
    • 1.2% (0.6%) - Ubuntu;
    • 0.8% (0.6%) - Scientific Linux,

  • Минимальный порог пиковой производительности для вхождения в Top500 вырос за полгода с 349.3 до 430.5 терафлопсов, а для Top100 - с 1073 до 1193 терафлопсов. Система, замыкающая нынешний рейтинг, в прошлом выпуске находилась на 393 месте;
  • Суммарная производительность всех систем в рейтинге за полгода возросла с 672 до 749 петафлопсов (три года назад было 274 петафлопсов). В настоящее время 138 кластеров демонстрирует производительность более петафлопcа (в прошлом рейтинге - 117, три года назад - 37);
  • Общее распределение по количеству суперкомпьютеров в разных частях света выглядит следующим образом: 212 суперкомпьютера находится в Азии (213 в предыдущем списке), 176 в Америке (175) и 106 в Европе (104);
  • В качестве процессорной основы лидируют CPU Intel - 92.8% (было 92.5%), на втором месте - IBM Power - 4.2% (было 4.4%), на третьем - AMD - 1.2% (было 1.4%);
  • 31.6% (31.8%) всех используемых процессоров имеют 12 ядер, 13.2% (13.4%) - десять, 12.8% (11.2%) - 16 ядер, 11.2% (15.8%) - 8 ядер, 9.6% - 14 ядер, 7% - 18 ядер. Двух- и одноядерные системы не входят в рейтинг;
  • 91 из 500 систем (в прошлом рейтинге - 86) дополнительно используют ускорители или сопроцессоры, при этом в 74 системах задействованы чипы NVIDIA (было 52), в 17 - Intel Xeon Phi (было 21), в 1 - GPU AMD (было 1), 2 - PEZY, в 13 используются гибридные решения (было 3);
  • Среди производителей кластеров на первом месте компания Hewlett-Packard 28.6% (22.4%), на втором месте - Lenovo 17% (18.4%), на третьем месте - Cray 11.4% (11.2%), на четвёртом - Sugon 9.2% (9.4%), на пятом - IBM 5.4% (6.6%).

Одновременно выпущен альтернативный рейтинг кластерных систем Graph 500, ориентированный на оценку производительности суперкомпьютерных платформ, связанных с симулированием физических процессов и задач по обработке больших массивов данных, свойственных для данных систем. Рейтинг Green500 отдельно больше не выпускается и объединён с Top500, так как обеспечение энергоэффективности теперь отражается в основном рейтинге Top500 (учитывается отношение LINPACK FLOPS к потребляемой мощности в ваттах).

  1. OpenNews: Вышел PelicanHPC 4.1, Linux-дистрибутив для развертывания кластеров
  2. OpenNews: Опубликована 47-я редакция списка самых высокопроизводительных суперкомпьютеров
  3. OpenNews: Выпуск кластерной ФС Lustre 2.8
  4. OpenNews: Опубликована 46-я редакция списка самых высокопроизводительных суперкомпьютеров
  5. OpenNews: Опубликована 48 редакция списка самых высокопроизводительных суперкомпьютеров
Обсуждение (57 +14) | Тип: К сведению |
23.06.2017 Ubuntu переходит на формат сетевой конфигурации netplan (203 –15)
  Разработчики Ubuntu сообщили о переводе находящегося в разработке осеннего выпуска дистрибутива (17.10) на использование системы netplan для хранения настроек сетевых интерфейсов, вместо ранее применяемого инструментария ifupdown, хранящего настройки в файле /etc/network/interfaces. Netplan обеспечивает хранение параметров в формате YAML и предоставляет бэкенды, абстрагирующие доступ к конфигурации для NetworkManager и systemd-networkd.

Для миграции на Netplan предусмотрена команда "netplan ifupdown-migrate", которая осуществляет преобразование старых настроек /etc/network/interfaces в формат netplan. Пользователям также предоставлена возможность продолжить использование ifupdown, явно установив данный пакет ("sudo apt install ifupdown"). В ежедневных сборках Ubuntu Server новая система уже задействована для записи сетевой конфигурации в каталог /etc/netplan. В Ubuntu Desktop простейшая конфигурация netplan уже применяется в NetworkManager, начиная с выпуска 16.10.

Применение netplan унифицирует определение базовых конфигурационных файлов, используемых в NetworkManager и systemd-networkd, избавляя от необходимости изучения деталей форматов конфигурации каждой из этих систем. Суть работы netplan сводится к тому, что в процессе начальной загрузки он читает базовые сетевые настройки из файлов "/{lib,etc,run}/netplan/*.yaml" и записывает конфигурацию в каталог /run в формате, подходящем для дальнейшей обработки сетевыми демонами (по умолчанию конфигурация передаётся systemd-networkd, но опционально поддерживается NetworkManager).

Из особенностей netplan также отмечается: игнорирование устройств, не отмеченных в конфигурации; вся конфигурация хранится только в исходном YAML-файле (без использования /etc/network/interfaces); поддерживается разбиение конфигурации на несколько файлов (например, для выноса настроек libvirt и lxd); гибкие возможности выбора и смены бэкенда. Из поддерживаемых команд отмечаются: "netplan generate" для генерации конфигурации для обработчиков (NetworkManager или systemd-networkd) на основе базовых YAML-настроек; "netplan apply" для применения всех настроек и перезапуска обработчиков.

Описание параметров сетевых интерфейсов в netplan осуществляется при помощи декларативного синтаксиса, позволяющего достаточно просто описать структуру сложной сети. Из достоинств netplan по сравнению с ifupdown отмечается декларативный синтаксис; возможность применения масок для имён сетевых интерфейсов, MAC-адресов, драйверов и других компонентов; учёт контекста при разборе иерархии параметров сетевых интерфейсов, что позволяет корректно и в правильном порядке передать настройки обработчикам (в ifupdown при разборе сложных конфигураций не исключено возникновение проблем, вызванных состоянием гонки).

В случае применения DHCP простейшая конфигурация netplan будет выглядеть следующим образом:



   network:
     version: 2
     ethernets:
        enp3s0:
            dhcp4: yes

Более сложный пример:


  network:
      version: 2

      ethernets:
        id0:
          match:
            macaddress: 00:11:22:33:44:55
          wakeonlan: true
          dhcp4: true
          addresses:
            - 192.168.14.2/24
            - 2001:1::1/64
          gateway4: 192.168.14.1
          gateway6: 2001:1::2
          nameservers:
            search: [foo.local, bar.local]
            addresses: [8.8.8.8]
        lom:
          match:
            driver: ixgbe
          set-name: lom1
          dhcp6: true
        switchports:
          match:
            name: enp2*
          mtu: 1280
      wifis:
        all-wlans:
          match: {}
          access-points:
            "Joe's home":
              password: "s3kr1t"
        wlp1s0:
          access-points:
            "guest":
               mode: ap
               channel: 11
      bridges:
        br0:
          interfaces: [wlp1s0, switchports]
          dhcp4: true
      routes:
       - to: 0.0.0.0/0
         via: 11.0.0.1
         metric: 3

  1. OpenNews: Разработчики systemd предложили новую систему для настройки сетевой конфигурации
  2. OpenNews: Релиз NSH 1.0, командной оболочки для настройки сетевых компонентов OpenBSD
  3. OpenNews: /etc/net - новый метод управления сетевой конфигурацией в Linux
  4. OpenNews: Первый стабильный релиз сетевого конфигуратора ConnMan
  5. OpenNews: В ArchLinux интегрирован новый сетевой конфигуратор netctl
Обсуждение (203 –15) | Тип: К сведению |
23.06.2017 Уязвимость во Flatpak, позволяющая повысить привилегии в системе (21 +4)
  В системе Flatpak, предоставляющей средства для создания самодостаточных пакетов, которые не привязаны к конкретным дистрибутивам Linux и выполняются в специальном изолированном контейнере, выявлена опасная уязвимость (CVE-2017-9780), позволяющая повысить свои привилегии в системе. Проблема устранена в выпуске Flatpak 0.8.7 и 0.9.6, а также в пакетах для Debian. Уязвимость пока остаётся неисправленной в репозиториях Fedora и Ubuntu.

Уязвимость позволяет подготовить вредоносный Flatpak-пакет, содержащего файлы с некорректными правами доступа, например с флагом setuid или открытые всем на запись. После установки такого пакета, подобные файлы сохраняются в локальной системе с теми же правами, что позволяет локальному атакующему добиться выполнения поставляемого в пакете исполняемого файла с флагом suid или организовать запись в области, доступные всем на запись. В случае, когда Flatpak-пакет содержит системный обработчик ("system helper"), компоненты которого принадлежат пользователю root (используется, когда Flatpak-пакет устанавливается для всех пользователей в системе), возможна организация запуска приложения с флагом setuid root.

Следует отметить, что запуск вредоносного Flatpak-пакета при помощи Flatpak не представляет опасности, так как он запускается в режиме PR_SET_NO_NEW_PRIVS, не допускающем смену привилегий. Но атака может быть совершена другим локальным пользователем, который может обратиться к установленным файлам Flatpak и запустить suid-файл напрямую, минуя инструментарий Flatpak, получив полномочия пользователя, под которым установлены файлы вредоносного Flatpak-пакета (root, в случае если пакет был установлен администратором для всей системы).

  1. OpenNews: Система изолированных контейнеров для графических приложений xdg-app переименована во flatpak
  2. OpenNews: Сформирована стабильная ветка системы самодостаточных пакетов Flatpak 0.8.0
  3. OpenNews: Значительный выпуск системы самодостаточных пакетов Flatpak 0.6.13
  4. OpenNews: Для Flatpak подготовлена технология управляемого доступа к ресурсам вне контейнера
  5. OpenNews: Первый выпуск Flatpak, самодостаточных пакетов для распространения графических приложений
Обсуждение (21 +4) | Тип: Проблемы безопасности |
22.06.2017 Серия критических уязвимостей в гипервизоре Xen (17 +5)
  В гипервизоре Xen выявлено 10 уязвимостей, из которых пять (XSA-224, XSA-222, XSA-219, XSA-218, XSA-217) потенциально позволяют выйти за пределы текущего гостевого окружения, две (XSA-225, XSA-223) дают возможность инициировать крах гипервизора из гостевой системы, а три уязвимости (XSA-221, XSA-220, XSA-216) могут привести к утечке содержимого памяти из адресного пространства других окружений или хост-системы.

Исправления пока доступны в виде патчей. CVE-идентификаторы пока не присвоены. Некоторые провайдеры публичных облачных систем были уведомлены о проблеме две недели назад и уже устранили уязвимость. Всем пользователям Xen и провайдерам, не включённым в список упреждающей отправки уведомлений, рекомендуется срочно установить обновление. Для эксплуатации наиболее опасных уязвимостей атакующий должен иметь доступ к выполнению кода в гостевой системе с правами ядра.

Особенности некоторых проблем:

  • XSA-224 - владелец гостевой системы в режиме паравиртуализации (PV) может получить доступ на запись в таблицу страниц памяти, связанных с его окружением. В итоге атакующий может получить доступ к системной памяти и поднять свои привилегии до уровня хост-системы. Проблеме подвержены только конфигурации на базе архитектуры x86, в которых используются гостевые системы в режиме PV. HVM-системы уязвимы только в случае использования узявимых PV-бэкендов, в которых используется вызов calls grant_map() с флагами GNTMAP_device_map и GNTMAP_host_map;
  • XSA-222 - из гостевого окружения можно получить доступ к памяти, не принадлежащей данному окружению из-за ошибки в организации повторного использования таблиц маппинга P2M (Physical-to-Machine), что потенциально может быть использовано для повышения своих привилегий (контроль за хост-системой) или привести к утечке данных от других окружений. Проблеме подвержены конфигурации Xen на базе архитектур x86 и ARM, но на x86 атака возможна только против окружений в режиме полной виртуализации (HVM). Для защиты можно указать в настройках HVM "hap_1gb=0 hap_2mb=0";
  • XSA-219 - при наличии одновременного контроля за двумя гостевыми системами, атакующий может получить доступ к хост-системе. Проблеме подвержены только системы x86. Для успешной атаки необходим доступ к окружениям HVM с поддержкой Shadow Mode Paging (в настройках "hap=0"). HVM-окружения в режиме Hardware Assisted Paging (HAP, в настройках "hap=1") проблеме не подвержены. Для атаки необходим одновременный доступ к PV-окружению и HVM-окружению, но теоретически не исключается возможность совершения атаки, при контроле за одним гостевым окружением в режиме полной вирутализации (HVM).
  • XSA-218 - состояние гонки, позволяющее в короткие моменты времени из подконтрольного злоумышленнику бэкенда прочитать или записать содержимое памяти чужого фронтэнда. В зависимости от ситуации уязвимость может использоваться для организации утечки конфеденциальных данных или повышения своих привилегий на стороне фронтэнда. Кроме того, отмечается ещё одна проблема, позволяющая непривилегированной гостевой системе из-за состояния гонки дважды очистить запись maptrack, что теоретически не исключает развитие атаки для выполнения кода на стороне хост-системы.
  • XSA-217 - при наличии контроля за двумя гостевыми системами можно получить доступ ко всей системной памяти, что может использоваться для повышения своих привилегий и организации утечки данных из хост-системы или других гостевых систем. Проблеме подвержены только системы x86 при наличии у атакующего контроля за двумя гостевыми системами в режиме PV и HVM (контроля за двумя PV или за двумя HVM недостаточно, для атаки необходим одновременный доступ и к PV и к HVM).
  • XSA-216 - утечка отрывков содержимого стека бэкенда через Linux-драйверы xen-blkback, blkback и blktap, используемые для доступа к блочным устройствам. Уязвимость позволяет непривилегированному гостевому окружению получить доступ к отрывкам конфиденциальной информации из хост-системы или другого гостевого окружения (речь про отрывки данных, оставленные бэкендом в полях добавочного заполнения (padding), неочищенные после прошлого запроса).

  1. OpenNews: Уязвимости в гипервизоре Xen, позволяющие выйти за пределы гостевого окружения
  2. OpenNews: Уязвимость в Xen, позволяющая выйти за пределы гостевой системы
  3. OpenNews: Релиз гипервизора Xen 4.8
  4. OpenNews: Уязвимость в Xen, позволяющая получить доступ к хост-системе
  5. OpenNews: Критическая уязвимость в Xen, позволяющая получить контроль над хост-системой
Обсуждение (17 +5) | Тип: Проблемы безопасности |
21.06.2017 Выпуск http-сервера Apache 2.4.26 с полноценной поддержкой HTTP/2 (34 +10)
  Доступен релиз HTTP-сервера Apache 2.4.26, в котором представлено 63 изменения, 22 из которых связаны с исправлениями в модуле mod_http2.

Из изменений можно отметить:

  • C модуля mod_http2 снята метка экспериментальной разработки, реализация протокола HTTP/2 отныне признана готовой для повсеместного применения;
  • Добавлен новый модуль mod_brotli для сжатия с использованием алгоритма Brotli (RFC 7932);
  • В файле конфигурации обеспечено выполнение вложенных блоков If/ElseIf/Else;
  • В mod_lua добавлена поддержка Lua 5.3;
  • Изменено поведение mod_rewrite: если подстановка является полным URL, а схема/хост/порт совпадают с текущим виртуальным хостом, то компонент пути в URL больше не интерпретируется как локальный путь, если он присутствует в файловой системе. Для возвращения старого поведения добавлена опция "RewriteOption LegacyPrefixDocRoot";
  • В mod_rewrite добавлен флаг 'BNP' (backreferences-no-plus), включающий замену пробелов в обратных ссылках RewriteRule на "%20" вместо "+";
  • В mod_rewrite добавлена возможность ограничения экранирования определённых символов через указание их в флаге "B";
  • В mod_env добавлен вывод предупреждения для директивы 'SetEnv', если в имени переменной окружения указан символ '=';
  • В mod_proxy_http2 добавлена поддержка заголовков Reverse Proxy Request;
  • В mod_proxy_fcgi добавлена директива ProxyFCGISetEnvIf для изменения переменных окружения CGI на стадии до вызова FastCGI;
  • В mod_proxy разрешено применение переменной окружения "no-proxy" в качестве альтернативы выражению "ProxyPass /path !";
  • В mod_proxy_fcgi возвращено старое поведение (2.4.20), оставляющее префикс "proxy:fcgi://" в переменной окружения SCRIPT_FILENAME;
  • В mod_proxy_http2 добавлена директива ProxyPreserverHost;
  • В mod_proxy_wstunnel добавлен параметр "upgrade", разрешающий обновление до другого протокола;
  • Проведена работа по увеличению производительности, качества буферизации и динамического регулирования потоком в mod_http2;
  • В mod_http2 директива MaxKeepAliveRequests теперь ограничивает число повторных использований slave-соединений;
  • В mod_http2 добавлена поддержка директивы MergeTrailers;
  • В mod_autoindex добавлена опция "IndexOptions UseOldDateFormat", позволяющая использовать формат Last Modified как в Apache 2.2;
  • В парсер выражений добавлена подстановка %{REMOTE_PORT};
  • Во вложенных SSI-выражениях подстановка %{DOCUMENT_URI} теперь всегда указывает на URI оригинального запроса, а не на URI вложенного документа;
  • В mod_ssl добавлена поддержка OpenSSL 1.1.0;
  • Устранено 5 уязвимостей:
    • CVE-2017-3167 - обход аутентификации при использовании ap_get_basic_auth_pw() в сторонних модулях;
    • CVE-2017-3169 - инициирование краха через отправку запроса HTTPS из-за разыменования нулевого указателя в mod_ssl;
    • CVE-2017-7659 - инициирование краха через отправку запроса HTTP/2 из-за разыменования нулевого указателя в mod_http2;
    • CVE-2017-7668 - чтение вне границ буфера в функции ap_find_token() может привести к краху при обработке специально оформленных заголовков запроса;
    • CVE-2017-7679 - чтение вне границ буфера в mod_mime может привести к чтению байта из области за пределами выделенного буфера при обработке специально оформленного заголовка Content-Type. Интересно, что о проблеме было сообщено ещё в ноябре 2015 года, а исправление внесено только сейчас.

    1. OpenNews: Релиз http-сервера Apache 2.4.25
    2. OpenNews: DoS-уязвимость в mod_http2 из состава http-сервера Apache
    3. OpenNews: В HTTP-сервере Apache 2.4.23 устранена уязвимость
    4. OpenNews: Выпуск nginx 1.9.5 с поддержкой HTTP/2
    5. OpenNews: Серия уязвимостей в реализациях HTTP/2
Обсуждение (34 +10) | Тип: Программы |
21.06.2017 В состав GCC одобрено включение языка программирования D (74 +42)
  Разработчики коллекции компиляторов GCC объявили о принятии решения по включению в число поставляемых в составе GCC компиляторов фронтэнда GDC (Gnu D Compiler) и runtime-компонентов, необходимых для сборки программ на языке программирования D.

Процесс включения поддержки языка D в GCC начался ещё в 2011 году, но затянулся из-за необходимости приведения кода к соответствию требованиям GCC и проблем с передачей прав на интеллектуальную собственность компании Digital Mars, развивающей язык программирования D. Проблемы с интеллектуальной собственностью были достаточно быстро решены, но для решения технических проблем и синхронизации разработки с компилятором DMD потребовалось почти полностью переписать GDC.

Язык D использует статическую типизацию, обладает синтаксисом, схожим с C/C++, и обеспечивает производительность компилируемых языков, при этом заимствуя некоторые полезные возможности динамических языков в области эффективности разработки и обеспечения безопасности. Например, предоставляется поддержка ассоциативных массивов, косвенное определение типов, автоматическое управление памятью, средства параллельного программирования, опциональный сборщик мусора, система шаблонов, компоненты для метапрограммирования, возможность использовать библиотеки на языке C, а также некоторые библиотеки на C++ и Objective-C.

  1. OpenNews: Для GCC подготовлен фронтэнд с поддержкой языка Rust, развиваемого проектом Mozilla
  2. OpenNews: Компания Google надеется на включение компилятора языка Go в GCC 4.6
  3. OpenNews: Компания Digital Mars намерена добиться включения в GCC компилятора для языка программирования D
  4. OpenNews: В состав GCC одобрено включение фронтэнда для языка Go
  5. OpenNews: Язык программирования D на пути к включению в состав GCC
Обсуждение (74 +42) | Тип: К сведению |
21.06.2017 Уязвимость в OpenVPN, которая может привести к выполнению кода на сервере (22 +12)
  Гвидо Вренкен (Guido Vranken), известный разработкой нескольких атак против различных реализаций SSL/TLS, опубликовал результаты fuzzing-тестирования кодовой базы пакета для создания виртуальных частных сетей OpenVPN, в результате которого им было выявлено 4 опасные уязвимости и две неопасные. Одна из уязвимостей потенциально может привести к выполнению кода на сервере.

Публикация сведений об уязвимостях скоординирована с разработчиками OpenVPN, благодаря чему уже опубликованы релизы OpenVPN 2.4.3 и 2.3.17, в которых устранены выявленные проблемы. При этом в дистрибутивах уязвимости пока остаются неисправлеными (Debian, RHEL, SUSE, Fedora, Ubuntu). Интересно, что незадолго до выявления уязвимостей, проект OpenVPN успешно прошёл два независимых аудита кодовой базы, которые не выявили данных проблем.

Наиболее опасная уязвимость (CVE-2017-7521) проявляется на серверах, использующих опцию "--x509-alt-username" и соответствующее расширение сертификата X.509. Аутентифицированный клиент, имеющий возможность подключения к серверу OpenVPN, может вызвать ситуацию двойного освобождения области памяти (double free), которая потенциально может быть эксплуатирована для организации выполнения кода на сервере. Для успешной эксплуатации требуется добиться, чтобы функция ASN1_STRING_to_UTF8() при вызове из extract_x509_extension() вернула значение False, что по предварительной оценке возможно при условии исчерпания доступной процессу памяти.

Другие уязвимости:

  • CVE-2017-7508 - возможность удалённо завершить работу сервера или клиента через отправку специально оформленного пакета IPv6. Проблема проявляется при включении опции "--mssfix";
  • CVE-2017-7512 - серия проблем в коде разбора сертификатов OpenSSL, вызванных утечкой нескольких байт памяти при обработке каждой попытки соединения. Сгенерировав большое число запросов, можно вызвать исчерпание всей доступной серверному процессу памяти и вызвать крах или подготовить условия для эксплуатации уязвимости CVE-2017-7521;
  • CVE-2017-7520 - возможность удалённого краха клиентского ПО или утечки информации со стороны клиента на стадии до проведения аутентификации (можно прочитать 96 лишних байт стека, которые вполне могут содержать пароль к прокси). Проблема вызвана возможностью чтения из области памяти вне границ буфера и проявляется в системах применяющих опцию "--http-proxy" совместно с аутентификацией через ntlm2. Эксплуатация может быть совершена путём модификации трафика в ходе MITM-атаки между клиентом и прокси;
  • CVE-2017-7522 - возможность вызова краха сервера, использующего опцию "--x509-track", при передаче аутентифицированным клиентом сертификата с нулевым символом в строке ASN.1. Проблема проявляется в конфигурациях, собранных с библиотекой mbed TLS/PolarSSL . Атака маловероятна так как требуется наличие заверенного удостоверяющим центром сертификата с нулевым символом;
  • Разыменование нулевого указателя в функции establish_http_proxy_passthru(), которое может быть использовано для инициирования краха клиента в случае незаполнения сервером полей 'realm' и 'nonce'.

  1. OpenNews: Выпуск OpenVPN 2.4.2, в котором отражены результаты аудита безопасности
  2. OpenNews: Завершён аудит проекта OpenVPN
  3. OpenNews: Доступен релиз OpenVPN 2.4.0
  4. OpenNews: Выпуск OpenVPN 2.3.6, 2.2.3 и 2.0.11 с устранением уязвимости
  5. OpenNews: Представлен Sweet32, новый вид атаки на HTTPS и OpenVPN
Обсуждение (22 +12) | Тип: Проблемы безопасности |
21.06.2017 Доступен аудиокодек Opus 1.2 (48 +33)
  Организация Xiph.Org, занимающаяся разработкой свободных видео- и аудиокодеков, представила релиз аудиокодека Opus 1.2.0, который отличается высоким качеством кодирования и минимальной задержкой как при сжатии потокового звука с высоким битрейтом, так и при сжатии голоса в ограниченных по пропускной способности приложениях VoIP-телефонии.

Ключевые новшества Opus 1.2:

  • Проведена работа по увеличению качества передачи голоса в диапазоне полосы пропускания 12-20 kbit/s. Значительно улучшена реализация гибридного режима передачи голоса, при котором для частот до 8 kHz применяется SILK, а с 8 до 20 kHz - CELT. Для повышения качества передачи голоса проведена настройка психоакустических методов. Обеспечено агрессивное занятие более широкой полосы пропускания при передаче голоса, включая начало передачи с битрейтом 14 kbit/s;
  • Улучшена реализация кодирования с переменным битрейтом (VBR) для гибридных режимов, кодировщик теперь использует VBR и для низких битрейтов, вплоть до 32 kb/s;
  • Проведена работа по увеличению качества передачи музыки в диапазоне битрейта 32-48 kbit/s. Если изначально Opus обеспечивал приемлемое качество только для битрейтов 64 kb/s и 96 kb/s, то применение улучшенной техники кодирования с переменным битрейтом позволило добиться возможности кодирования музыки с битретеми 32-48 kbit/s без возникновения слышимых артефактов;
  • Проведена обширная оптимизация, которая позволила снизить нагрузку на CPU и увеличить производительность. Внесены как общие оптимизации качества кода, так и задействованы специфичные процессорные инструкции SSE* для x86 и Neon для ARM. Улучшение качества кода определения типа CPU позволило включить аппаратные оптимизации на этапе компиляции даже при использовании старых CPU;
  • Поддержка прямого кодирования кадров, продолжительностью 80, 100 и 120 мс, без применения repacketizer, который получал кадр в 120 мс путём объединения двух кадров по 60 мс;
  • Для режима CELT представлена поддержка DTX (Discontinuous transmission, остановка передачи во время пауз в разговоре);
  • Улучшено качество передачи с постоянным битрейтом (CBR) в режиме SILK при низких битрейтах;
  • Улучшена реализация техники упреждающей коррекции ошибок (FEC, forward-error correction), полезной в условиях большой потери пакетов в канале связи. FEC теперь может применяться на более низких битрейтах (до 24 kb/s), чем раньше, и учитывается при распределении битового потока в гибридном режиме;
  • Для платформы Windows реализация Opus теперь поставляется в виде одной библиотеки, без выделения SILK и CELT в разные DLL;
  • Реализована, но пока не добавлена в стандарт, поддержка режима сферического объёмного звучания Ambisonics, востребованного в системах виртуальной реальности. В Opus 1.2 уже поддерживается метод прямого кодирования каналов ambisonics, но пока отсутствует матричное кодирование.

Напомним, что кодек Opus создан путем комбинации лучших технологий из разработанного организацией Xiph.org кодека CELT и открытого компанией Skype кодека SILK. Кроме Skype и Xiph.Org в разработке Opus также приняли участие такие компании, как Mozilla, Octasic, Broadcom и Google. Opus отличается высоким качеством кодирования и минимальной задержкой как при сжатии потокового звука с высоким битрейтом, так и при сжатии голоса в ограниченных по пропускной способности приложениях VoIP-телефонии. Ранее Opus был признан лучшим кодеком при использовании битрейта 64Kbit (Opus обогнал таких конкурентов, как Apple HE-AAC, Nero HE-AAC, Vorbis и AAC LC). Из продуктов, поддерживающих Opus из коробки, можно отметить браузер Firefox, фреймворк GStreamer и пакет FFmpeg.

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

Основные возможности Opus:

  • Битрейт от 6 до 510 Kbit/s;
  • Частота дискретизации от 8 до 48KHz;
  • Продолжительность кадров от 2.5 до 120 миллисекунд;
  • Поддержка постоянного (CBR) и переменного (VBR) битрейтов;
  • Поддержка узкополосного и широкополосного звука;
  • Поддержка голоса и музыки;
  • Поддержка стерео и моно;
  • Поддержка динамической настройки битрейта, пропускной способности и размера кадра;
  • Возможность восстановления звукового потока в случае потери кадров (PLC);
  • Поддержка до 255 каналов (многопоточные кадры)
  • Доступность реализаций с использованием арифметики с плавающей и фиксированной запятой.

  1. OpenNews: Доступен аудиокодек Opus 1.1.3
  2. OpenNews: Доступен аудиокодек Opus 1.1.1
  3. OpenNews: Стабильный выпуск аудиокодека Opus 1.1
  4. OpenNews: Разработчики Mozilla разобрали ситуацию с нарушением патента в кодеке Opus
  5. OpenNews: Публикация RFC ознаменовала первый стабильный релиз свободного аудиокодека Opus
Обсуждение (48 +33) | Тип: Программы |
Следующая страница (раньше) >>


  Закладки на сайте
  Проследить за страницей
Created 1996-2017 by Maxim Chirkov  
ДобавитьРекламаВебмастеруГИД  
Hosting by Ihor TopList