Скоро бинарные баги в браузерах получат перерождение за счёт wasm: https://blog.mozilla.org/blog/2017/11/13/webassembly-in-browsers/

На фоне хайпа с сайд-ченнел багой в Chromium 64 выкатывается набор фиксов, снижающих вероятность эксплуатации баги: https://www.chromium.org/Home/chromium-security/ssca. То же самое сделали и MS: https://blogs.windows.com/msedgedev/2018/01/03/speculative-execution-mitigations-microsoft-edge-internet-explorer/ с теми же самыми исправлениями: отключение SharedArrayBuffer и тюнинг performance.now()

Набор фиксов для Meltdown и Spectre в Chromium'е можно наблюдать в коммитах: https://chromium.googlesource.com/chromium/src/+/953bf5bfd1957a9c6c123d8dfc59254dcd7bb956
(патч perfomance.now()), https://chromium.googlesource.com/chromium/src/+/62fc5a081ba836bf4983f3b3ff4ec08382ac4c25 (отключение SharedBuffers по умолчанию)

А тем временем WebKit заявил еще и о новых фиксах для Spectre и Meltdown, в частности, в Safari есть доп. защита от спекулятивного исполнения в виде 2-х техник: Index masking и Pointer poisoning, подробности тут: https://webkit.org/blog/8048/what-spectre-and-meltdown-mean-for-webkit/

В MS Edge также появились нужные фиксы (что не новость), коммиты, но я пока что нашел только исправление с отключением SharedArrayBuffer: https://github.com/Microsoft/ChakraCore/pull/4503/commits/ee2538d7b38be8093d9c9341d761d4e8267050bc
Кстати, по ссылке еще целый ряд интересных исправлений безопасности =)

DOM XSS, вектор которых был через location.hash, похоже, умрет в Chrome начиная с 65 версии. Теперь, hash как часть URL будет в urlencode.

Получил в личку ряд вопросов о том, как именно от Spectre помогает режим strict site isolation.
Все просто - если включить этот режим, в хромиуме перестает работать SharedArrayBuffer.
Можете проверить сами:
1. включите на 63 хромиуме strict site isolation chrome://flags/#enable-site-per-process;
2. запустите тестовый PoC отсюда: https://github.com/ascendr/spectre-chrome, либо отсюда: http://xlab.tencent.com/special/spectre/spectre_check.html.

P.S. Если вдруг проверка не удалась, попробуйте удалить UserData, скорее всего вам уже прилетело отключение SharedArrayBuffer через конфиг экспериментов.

В добавление к предыдущему посту. Конечно же, помимо фикса SharedArrayBuffer в режиме strict site isolation очень важным является и то, что данные от разных сайтов (которые могут попасть в процесс вкладки за счёт наличия на сайте frame’ов и frameset’ов) будут жить в разных процессах, что не позволит аткующему их украсть через Spectre. Если бы для исправления хватало только отключения SharedBuffer, его можно было бы сделать через отдельный флаг chrome://flags/#shared-array-buffer.
Спасибо @xima_era за то, что обратил на это внимание!

Отличные нововости для любителей огненной лисы!
15 января в своем блоге Mozilla объявила о том, что все новые фичи, взаимодействующие с веб-ресурсами, должны работать по умолчанию только в защищенных контекстах (secure context). В исключения попадают фичи, которые другие браузеры уже реализовали в незащищенном контексте, либо которые реализовать в защищенном контексте очень сложно. Прочитать про это можно тут: https://blog.mozilla.org/security/2018/01/15/secure-contexts-everywhere/.

Для справки. Под контекстом в браузерах подразумевается среда исполнения, в которой существует объект Document (т.е. по сути это window-объект, который пораждается новой вкладкой, iframe'ом или frameset'ом). Защищенным контекстом называется контекст, в котором передача исполняемого кода идет зашифрованному и аутентифицированному каналу (т.е. по https). Подробнее про это можно почитать тут: https://w3c.github.io/webappsec-secure-contexts.

ProjectZero раскрыл детали по двум новым и интересным memory corruption уязвимостям в Ms Edge. На этот раз это out of bounds write в Chakra Jit (CVE-2018-0777 и CVE-2018-0769), детали и PoCи есть по ссылкам: https://bugs.chromium.org/p/project-zero/issues/detail?id=1429, https://bugs.chromium.org/p/project-zero/issues/detail?id=1390. А также out of bounds read в ChakraAsmJs (CVE-2018-0780): https://bugs.chromium.org/p/project-zero/issues/detail?id=1433. Это то, что было исправлено MS в январе.

В продолжение утренней темы, ознакомиться с примерами уязвимостей в Chakra, которые были найдены Project Zero за 2016 и 2017, можно по ссылке: https://bugs.chromium.org/p/project-zero/issues/list?can=1&q=chakra. Спасибо, loki и natashenka!

Новый день - новые баги! Lokihardt из Google снова открыл детали по уязвимости, позволяющей копировать данные из стека в heap средствами JavaScript в Chakra(CVE-2017-0776). https://bugs.chromium.org/p/project-zero/issues/detail?id=1420.

Я уже писал ранее про бинарные баги в браузерах, связанные с web assembly. И вот первый известный мне экземлпяр: CVE-2017-5116, которая была обнаружена в JavaScript движке V8, а значит и в Chrome (для версии 61.0.3163.79 для десктопа и 61.0.3163.81 для Android). Детали по уязвимости появились сегодня.

Эта out of bounds бага возникает из-за race condition'а при доступе к уже полюбившемуся нам SharedArrayBuffer, содержащему WebAssembly код, из web-worker'а, который выполняется в другом потоке вкладки. Возникновение этой ситуации позволяет модифицировать WebAssembly-код, что в свою очередь позволяет атакующему получить read/write примитив. Подробное описание и технические детали есть тут: https://android-developers.googleblog.com/2018/01/android-security-ecosystem-investments.html.

Там же есть детали по баге CVE-2017-14904.
С помощью двух этих уязвимостей удалось взломать Google Pixel, который выжил и остался невзломанным в ходе Mobile Pwn2Own 2017.

Дошли руки посмотреть на исправления безопасности в новом релизе Chrome от 24 января (https://chromereleases.googleblog.com/2018/01/stable-channel-update-for-desktop_24.html). Мое внимание в этот раз привлекла уязвимость: “Same origin bypass in Shared Worker”. Видим, что id баги: 787103, доступ в нее, конечно, закрыт, а узнать детали хочется. Что же делать? Анализировать changelog!

Если под руками есть исходники Chromium’а, можно искать нужные коммиты через git, примерно так:

git log --all --grep="787103"


Если их нет, а тратить время на скачивание не хочется, можно пойти другим путём:

1. берем утилиту https://github.com/andreyka/chromium_bug_search и запускаем ее, передав id и название релиза:


python console.py -b 787103 -r 64.0.3282.119


2. получаем сообщение:


Commit found:
https://chromium.googlesource.com/chromium/src/+/018bb6d300c11acb953d51ef3cbec4cdcaf4a652


идем по ссылке в коммит и находим в его описании поле Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/781539.

3. проваливаемся в ревью, изучаем изменения, в конце видим 2 layout теста:

workers/data-url-shared.html;
data-url-shared-window.html.

По их коду видно, что уязвимость позволяет SharedWorrker’у с каким-то удаленным origin’ом получить доступ к MessageChannel’у c origin’ом null. Т.е из-за баги worker получает доступ к каналу чужого веб-ресусра.

Упрощенный локальный PoC на основе теста лежит тут: https://github.com/andreyka/PoCs/tree/master/CVE-2018-6032.

38 часов назад открыли детали интересной use after free баги в Jit V8 (CVE-2017-15399) с PoC, который умеет вызвать калькулятор в Chromium (если конечно запустить браузер с опцией —no-sandbox). Подробности тут: https://bugs.chromium.org/p/chromium/issues/detail?id=776677.

Но PoC для use after free баги в Jit V8 (CVE-2017-15399) можно было найти и раньше.
Вспоминаем недавнюю утилиту https://github.com/andreyka/chromium_bug_search и повторяем сценарий, но уже для этой CVE.

ID тикета мы бы получили из новости об этом релизе https://chromereleases.googleblog.com/2017/11/stable-channel-update-for-desktop.html, которая была опубликована 6 Ноября.

[776677] High CVE-2017-15399: Use after free in V8

Указываем ID тикета и что мы ищем ошибку в v8:

```python console.py -b 776677 -p v8 -r master
[+] Commit found:
https://chromium.googlesource.com/v8/v8/+/5f960dfc06a7c95af69e2b09f772b2280168469b```

В итоге попадаем в коммит https://chromium.googlesource.com/v8/v8/+/5f960dfc06a7c95af69e2b09f772b2280168469b, где видим готовый JS PoC - https://chromium.googlesource.com/v8/v8/+/5f960dfc06a7c95af69e2b09f772b2280168469b/test/mjsunit/regress/wasm/regress-776677.js, который был опубликован 23 Октября
#expdev #uaf #chrome

2 дня назад вышел новый отчет об улучшениях в безопасности Chromium'а, которые были сделаны в Q4 2017 года
Что там интересного:

- начиная с версии 63, у Chromium работает блокировка Cross-Site документов (HTML, XML и JSON), если включен режим site-isolation (http://www.chromium.org/developers/design-documents/blocking-cross-site-documents);

- также с 63 версии https://accounts.google.com теперь работает в выделенном рендререре;

- в Google начали разрабатывать Mac Sandbox V2, в котором так называемая warmup phase в macOS, которая сейчас будет работать уже в sandbox'е (https://chromium.googlesource.com/chromium/src.git/+/master/sandbox/mac/seatbelt_sandbox_design.md);

- c 23 ноября на 100% пользователей выкатили новый Chrome Cleanup Tool, улучшенный антивирусными технологиями ESET.

Полный отчет можно прочитать тут: https://dev.chromium.org/Home/chromium-security/quarterly-updates#TOC-Q4-2017

В Project Zero нашли интересный способ обойти sandbox Chromium'а.

Они обнаружили, что из рендерера в sandboх'е можно было вызвать интерфейс filesystem::mojom::Directory, который предоставлялся сервисом "catalog" и был инициализирован неправильно.
В частности, в Linux возможно было получить доступ к директории с бинарником браузера.

Подробности тут: https://bugs.chromium.org/p/project-zero/issues/detail?id=1450.

Фикс, который сделали в Chromium'е тут: https://chromium-review.googlesource.com/c/chromium/src/+/804397.

Ivan Fratric удачно пофаззил WebKit и сегодня открыл детали сразу по двум use after free багам:
https://bugs.chromium.org/p/project-zero/issues/detail?id=1465;
https://bugs.chromium.org/p/project-zero/issues/detail?id=1477. В последнем Safari у меня уже не работает.

Пока я был в небольшом творческом отпуске, в Chromium'e, FF и MS Edge нашли новый вид browlock'а.
Информация о том, что атаку уже используют ITW пришла от Malwarebytes еще в начале февраля (https://blog.malwarebytes.com/malwarebytes-news/2018/02/tech-support-scammers-find-new-way-jam-google-chrome/).

Для справки. Browlock - атака на браузер, при которой отдельная вкладка (или даже весь браузерный UI) не закрывается до тех пор, пока пользователь не выполнит нужное атакующему действие: например, выполнить денежный перевод, установить в браузер расширение и т.п.

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

Детали и PoC для Chromium есть тут: https://bugs.chromium.org/p/chromium/issues/detail?id=809775, в 65 версии хрома (которая пока еще в бете) блокировка уже не воспроизводится. Причем атака срабатывает, даже если пользователь не разрешил странице загружать несколько файлов одновременно.

Для Firefox тут (та же самая техника, что и в Chromium):
https://bugzilla.mozilla.org/show_bug.cgi?id=1438214
https://bugzilla.mozilla.org/attachment.cgi?id=8950967&action=edit

Для атак на Edge и IE используется функция:

navigator.msSaveOrOpenBlob()

но мои тесты показали, что поведение данного концепта в Edge (как и в FF) сильно зависит от версии и мощности компьютера, в старых версиях у меня просто подвисал интерфейс, но через некоторое время закрыть вкладку было можно.

Для Safari данный метод не является актуальным - блокировки интерфейса не происходит.

На днях твиттер принес упоминание об очень забавном тикете в Chromium:
https://bugs.chromium.org/p/chromium/issues/detail?id=588766. Суть в том, что можно задетектить использование инкогнито вкладки, подключив на страницу ресурс из расширения, которое в икогнито не работает по умолчанию. Тогда, через onerror обработчик, можно ловить факт того, что ресуср не загрузился, а значит - пользователь во вкладке инкогнито.

Вообще-то во многих браузерах (кроме Safari версии 11+, браузеров под Apple iOS и Firefox Focus) обнаружить инкогнито при первом же посещении сайта можно через JavaScript API. Хороший PoC есть тут: https://jsfiddle.net/wsk6m6rc/.