Более половины npm-пакетов могли быть скомпрометированы из-за ненадёжных паролей доступа

Никита Сковорода, входящий в управляющий технический комитет проекта 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%) указали в качестве пароля свой логин;
  • После сброса паролей 9.7% пользователей сразу вернули свой старый заведомо скомпрометированный пароль, а 0.6% вернули старый пароль, но внеся в него незначительное изменение;
  • Трафик всех пакетов, к которым был получен доступ в ходе исследования, составляет почти два миллиарда (1 946 302 172) загрузок в месяц, что примерно 20% от общего объёма загрузок.

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

Разработчик языка XL опубликовал новую сборочную систему build

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   

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

Выпуск рабочего стола Lumina 1.3

Сформирован релиз легковесного окружения рабочего стола 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 и т.п.);

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

Проект Debian уведомил о проблемах с CPU Intel Skylake и Kaby Lake

Разработчики дистрибутива 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    

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

В OpenBSD добавлена новая защита от атак на основе заимствования кусков кода

В состав OpenBSD принят набор патчей с реализацией технологии Trapsleds, позволяющей усложнить выполнение эксплоитов, использующих технику заимствования кусков кода, основанную на приёмах возвратно-ориентированного программирования (ROP, Return-Oriented Programming).

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

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

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

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

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

Опубликован 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 к потребляемой мощности в ваттах).

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

    Ubuntu переходит на формат сетевой конфигурации netplan

    Разработчики 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  

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

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

    В системе 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, в случае если пакет был установлен администратором для всей системы).

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

    Серия критических уязвимостей в гипервизоре Xen

    В гипервизоре 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), неочищенные после прошлого запроса).

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

    Выпуск http-сервера Apache 2.4.26 с полноценной поддержкой HTTP/2

    Доступен релиз 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 года, а исправление внесено только сейчас.

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

    В состав GCC одобрено включение языка программирования D

    Разработчики коллекции компиляторов GCC объявили о принятии решения по включению в число поставляемых в составе GCC компиляторов фронтэнда GDC (Gnu D Compiler) и runtime-компонентов, необходимых для сборки программ на языке программирования D.

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

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

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

    Серия критических уязвимостей в OpenVPN

    Гвидо Вренкен (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, что по предварительной оценке возможно в условии исчерпания доступной процессу памяти.

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