Компания Exodus Intelligence, специализирующейся на продаже спецслужбам и корпорациям информации о неисправленных уязвимостях, обратила внимание (https://blog.exodusintel.com/2019/04/03/a-window-of-opportunity/) на слабое место в процессе устранения уязвимостей в браузере Chrome, позволяющее злоумышленникам получать информацию о проблемах и создавать эксплоиты ещё до выпуска обновления браузера с устранением уязвимости. Проблема касается утечки сведений о проблемах в исправлениях, вносимых в JavaScript-движок V8.
Информация об уязвимостях в Chrome до выпуска релиза обрабатывается в закрытых отчётах об ошибках, доступных только небольшой группе основных разработчиков и не публикуемых публично до выхода исправлений. В случае, если уязвимость касается движка V8, исправления вносятся в его кодовую базу отдельно и некоторое время уязвимость становится исправленной в V8, но не исправленной в Chrome. Злоумышленники могут отследить подобные исправлений, проанализировать их и использовать для атаки на актуальные выпуски Chrome, воспользовавшись тем, что какое-то время уже засветившаяся в коде V8 проблема остаётся неисправленной в Chrome.
В качестве демонстрации своей теории, исследовали подготовили рабочий прототип эксплоита (https://github.com/exodusintel/Chromium-941743/), позволяющий атаковать полностью обновлённые выпуски Chrome. Эксплоит позволяет запустить системный калькулятор при открытии специально оформленной страницы, но для работы требует запуска браузера с опцией "--no-sandbox" для отключения sandbox-окружения. Эксплоит ограничен одной уязвимостью чтобы разработкой не могли воспользоваться злоумышленники и применить ещё не исправленную уязвимость для совершения злонамеренных действий (для совершения реальной атаки требуется выявление ещё одной уязвимости для выхода из sandbox).
Предложенный эксплоит был подготовлен по следам ошибки (https://chromium-review.googlesource.com/c/v8/v8/+/1526018) в реализации Array.prototype.map, которая исправлена в V8 18 марта, но остаётся неисправленной в Chrome. В случае, если бы эксплоит по мотивам данной ошибки был создан злоумышленниками, которые дополнительно имели сведения об ещё одной уязвимости для обхода sandbox, то они могли около двух недель применять этот эксплоит для атак на пользователей с самой свежей версией Chrome.
Текущий процесс разработки Chrome включает стадии для тестирования изменений перед их поставкой в финальном релизе. Например, используемая в эксплоите проблема вначале была исправлена в кодовой базе Chromium, после этого перенесена в экспериментальные ветки Chrome
Canary и Beta для тестирования перед включением в стабильную ветку. Время тестирования обычно занимает от нескольких дней до нескольких недель.URL: https://blog.exodusintel.com/2019/04/03/a-window-of-opportunity/
Новость: https://www.opennet.dev/opennews/art.shtml?num=50457
>>но для работы требует запуска браузера с опцией "--no-sandbox" для отключения sandbox-окружения.Гениально. Ждем уязвимость, требующую для эксплуатации пересборки браузера.
>>>но для работы требует запуска браузера с опцией "--no-sandbox" для отключения sandbox-окружения.
> Гениально. Ждем уязвимость, требующую для эксплуатации пересборки браузера.Хм, какие именно слова или буквы в
> Эксплоит ограничен одной уязвимостью чтобы разработкой не могли воспользоваться злоумышленникивам не понятны?
А то ведь можно сразу не заморачиваться, превентивно удалить калькулятор и гордо заявлять, что уязвимость (и заодно еще куча других) в этой конкретной системе не действует!
Мне сообщили, что в Cisco уже так и сделали.
>Проблема касается утечки сведений о потенциальных уязвимостях в исправлениях, вносимых в JavaScript-движок V8 и прочие отдельно разрабатываемые компоненты.Это шпионажем называется и за это срок полагается. Но сотрудники спецслужб почему-то неподсудны.
есть 2 мира: те, кого пасут и те, кто пасёт. законодательство написано для первых.
А, ну всё. "Давайте закрыать теперь репы11". Хотя проблема про это. :)
Вот беда-то! А если софт открыт и собран из библиотек, то я бибилотеку обновил, и... Опа. Всё пучком.Но:
а) собирателя из гугла что-то не очень мастаки собирать с отдельно выделенными бибилиотеками; им, видите ли, проще всё в проект запихать; (такой же привет Electron'щикам)
б) а можно ли V8 либой заиметь?
> Вот беда-то! А если софт открыт и собран из библиотек, то я
> бибилотеку обновил, и... Опа. Всё пучком.
> Но:
> а) собирателя из гугла что-то не очень мастаки собирать с отдельно выделенными
> бибилиотеками; им, видите ли, проще всё в проект запихать; (такой же
> привет Electron'щикам)
> б) а можно ли V8 либой заиметь?я бы фаерфокс хотел "из либ" а не монолитом (почти целиком?)
Жирнопанда частично собирается из либ, в частности либы harfbuzz icu libvpx sqlite webp могут быть системными и не создают проблем (уже были примеры, когда несовместимые либы рандомно крашили его). Но возникает ещё и другая проблема: версии системных либ будут ограничены теми, что поддерживаются браузером. Т.е. ты не сможешь либу на несовместимую. Можно делать как в NixOS, только это ничем не лучше.
не надо ля-ля!..about:buildconfig
CONFIG_SHELL=/bin/sh PYTHON3=/usr/local/bin/python3.6 --enable-application=browser --enable-update-channel=release --disable-tests CC=/usr/local/llvm80/bin/clang CXX=/usr/local/llvm80/bin/clang++ --disable-debug-symbols 'RUSTFLAGS=-C opt-level=3 -C target-cpu=x86-64' PKG_CONFIG=/usr/local/bin/pkgconf --enable-alsa --disable-pulseaudio LLVM_CONFIG=/usr/local/llvm80/bin/llvm-config --enable-system-ffi --with-system-webp --with-system-graphite2 --with-system-harfbuzz --with-system-jpeg=/usr/local PERL=/usr/local/bin/perl MAKE=/usr/local/bin/gmake --disable-crashreporter --disable-gconf --enable-install-strip --disable-libproxy --disable-necko-wifi --enable-official-branding --disable-parental-controls --enable-startup-notification --enable-strip --enable-system-pixman --enable-system-sqlite --disable-updater --prefix=/usr/local --with-intl-api --with-system-bz2 --with-system-icu --with-system-libevent --with-system-nspr --with-system-nss --with-system-png=/usr/local --with-system-zlib
найдите мне в вышеприведенном --without-system*
вышел, скажем, новый icu, пересобрали фф (т.к. мейнтенеры заботливо уведомили увеличением циферьки ребилда) и продолжаем радоваться жизни...
P.S. $ uname -srm
FreeBSD 12.0-RELEASE-p3 amd64
> Вот беда-то! А если софт открыт и собран из библиотек, то я бибилотеку обновил, и... Опа. Всё пучком.Как повезёт. Бывает и по другому. Библиотеку обновил - и у тебя приложение колом встало, потому что логика или API поменялось или ещё какая несовместимость вылезла. Нельзя просто взять и обновить зависимости. Надо сначала провести интеграционное тестирование, убедиться что оно и в самом деле может работать вместе.
Как бы да, но нет.
Если API поменялось на несовместимое, а циферку major не поменяли - ай-яй-я разработчикам/мейнтейнерам либы.
Остюда два: отвал браузера я таки замечу, не такая беда, и буду вынужден откатиться.
Тут вопрос в том, что в идеале мейнтейнер браузерного пакета должён бы проверить работоспособность с новой либой и, если что не так, не обновлять и зарепортить мейнтейнерам / разработчикам либы.
Но этож офигеешь проверять все кейсы браузера, если только так, на самых основных сайтах. Чтобы всё прогнать, надо многомного тестов.
> Библиотеку обновил - и у тебя приложение колом встало, потому что логика или API поменялось или ещё какая несовместимость вылезла.Значит, у тебя дистрибутив неправильный.