Как-то обошли на Хабре недавнюю Magellan-ошибку и связанные с ней уязвимости, попробую исправить это упущение.
Немного истории
- 1 Ноября 2018 в Chromium прилетел баг-репорт за номером 900910: "Multiple issues in SQLite via WebSQL." Об ошибке сообщает Wenxiang Qian из Tencent Blade Team.
- 5 Ноября 2018 ошибку закрывают в ядре библиотеки SQLite (FTS3), где она собственно и живет чуть не со времен создания модуля, т.е. с ноября 2009-го года.
- 28 Ноября 2018 оно вливается в Chromium
- Чуть позже Tencent Blade Team публикует сообщение об ошибке, дав ей название Magellan, особенно не раскрывая при этом подробностей, и указав, что публикация готовых эксплойтов и PoC пока не планируется.
- Через неделю в интернете полно PoC, крэшащих Chrome, Electron dev-framework и т.п. Доказательств и каких-либо других сведений, что уязвимость использовалась в злонамеренных целях по прежнему нет.
- DRH, подтвердил подозрения на Hacker News, что уязвимость имеет место (как минимум если допускается исполнение "чужого" SQL-запроса, или SQL Injection подобного сценария).
Что может быть подвержено уязвимости?
Потенциально, все устройства и программы, использующие SQLite (с включенным FTS) или использующие или на нем базирующиеся приложения (как например Chromium). Степень насколько они могут быть затронуты и эффект возможного "поражения" зависят от того, найден ли подходящий вектор атаки.
Немного подробнее о Magellan SQLite BUG
Ошибка связана с переполнением суммы целых чисел aka integer overflow, которая может быть вызвана в подсистеме FTS3/4 изменением индекса FTS таблицы, что в свою очередь может привести к переписыванию памяти или завершению с исключением.
Целевое искусственное применение этого целочисленного переполнения, посредством грамотного "обрезания" буферов записи, приводит к переполнению памяти, и может использоваться в дальнейшем специально созданными SQL-запросами.
В результате, в теории могут быть уязвимы многие приложения, использующие SQLite (с виртуальными FTS таблицами) и в частности популярные браузеры, поддерживающие WebSQL на базе SQLite с включенным FTS (например Google Chrome, Chromium, Opera, Slimjet Browser, SRWare Iron, Torch, Comodo Dragon, CoolNovo, Yandex Browser, Vivaldi и т.д.).
Базы данных SQLite вообще очень популярны, предоставляются средствами не одного десятка языков программирования, toolchain, фреймворков и т.д., используются приложениями как для мобильных устройств, так и полноценных компьютеров, и нередко встречаются даже в серверных решениях. Так, например, в этом формате хранят данные популярные веб-браузеры, такие как Google Chrome, Mozilla Firefox и Yandex Browser, множество мессенджеров (например, WhatsApp, Viber, WeChat и другие), и т.д. и т.п.
Тот же Fossil SCM, например, использует базу данных SQLite для хранения истории ревизий и позволяет использовать полнотекстовое индексирование через FTS (и предоставляет доступ к ней из UI/веб-морды, где например есть возможность создания собственных SQL-запросов, к примеру custom ticket reports и т.п.).
Update: DRH, являясь по совместительству соавтором и разработчиком Fossil, по всей видимости подумал про то же, и уже "закрыл дырку" обновлением SQLite до 3.26.0
Такое "предсказуемое" переполнение и само по себе не очень приятная штука, а если вспомнить, что конкретно может храниться и в самой банке (от содержимого журналов до собственно таблиц)…
Так-что не ленимся товарищи..., и обновляемся, обновляемся.
Где взять фикс?
Исправление [940f2adc8541a838] предоставляется в рамках обновления SQLite 3.25.3 (до которого также обновились Chromium и ко., например Chrome в версии 71.0.3578.80).
Версия SQLite 3.26 предоставляет также дополнительные возможности защиты FTS-контейнеров, например:
support for read-only shadow tables when the SQLITE_DBCONFIG_DEFENSIVE option is enabled
Какова опасность этой уязвимости?
Критична. Позволяет remote code execution. Вероятны также утечка памяти и аварийное завершение работы программ.
Есть ли примеры готовых exploit-ов, позволяющие использовать уязвимость?
Да.
В частности, Tencent Blade Team заявляют, что они успешно провели атаку на Google Home используя эту уязвимость (доступ к описанию issue на баг-трекере Google закрыт), и как уже выше сказано, в настоящее время раскрытие кода эксплойта не планируется.
Условия использования уязвимости?
Уязвимость может быть выполнена удаленно, например при вызове определенной веб-страницы в браузере, или при любом похожем сценарии, например позволяющем выполнять инструкции SQL (если FTS не отключен, при обнаружении возможного вектора атаки и/или наличия или возникновения некоторых других факторов, способствующих эксплуатации уязвимости).
Это кстати уже не первая ошибка вида overflow & buffer overrun в SQLite конкретно и в FTS модуле в частности (например [56be976859294027]), однако вероятно крупнейшая в своем роде по значимости, теоретическому воздействию и относительной "масштабности" в способах возможного применения и оценке последствий этого.
Комментарии (7)
Beholder
19.12.2018 12:36-1Ну продолжайте разрешать браузерам выполнять скрипты на любых произвольных сайтах…
rgrits
Интересно, как измерялась «значимость» и «масштабность» этого переполнения буфера по сравнению с другими. Чем эта выявленная дыра масштабнее других переполнений(выявленных и невыявленных)?
sebres Автор
То было во первых — ИМХО (извиняюсь, если не понятно).
Ну и хоть «значимость» и «масштабность» невыявленных дыр я оценивать не возьмусь :)
про конкретно эту — ну я, на вскидку, с десяток проектов могу назвать, где оно актуально (и я не про дериваты сейчас), ибо для некоторых сам воспроизводил магеллан на ура с «предсказуемымо» повторяющимся результатом, для других как минимум могу представить примерный сценарий для вектора «атаки».
Готового эксплойта я по понятным причинам тут не дам… (пусть скрипт-киддис сами ищут)… Но если уметь читать исходники и взглянуть на тесты в фиксе, то многое становится понятнее при оценке «значимости». Про «масштабность» же — думаю и так должно быть понятно (например, вы слово WebSQL в тексте заметили? и с какого года оно было невыявлено?).
rgrits
По мне так выявленная дыра она или есть или её нет. То есть это бинарное состояние. Значимость — это уже исключительно приписываемое свойство, а не объективное.
sebres Автор
Во первых, важна не столько сама ошибка, сколько возможность использовать ее как средство «атаки», сложность создания эксплойта на предмет например «remote code execution» и иже с ним, повторяемость (или стабильность) этого вектора в живой системе, и собственно (если про масштабность) — распространенность функционала в контексте возможного применения ошибки.
Во вторых, не каждая ошибка — есть сразу «дыра». О чем собственно и речь выше.
rgrits
Сравниваются переполнения буфера. И почему-то одно переполнение буфера является более масштабным и значимым. Зря я в эту дискуссию влез, только карму себе порчу. Объяснить что именно делает одну ошибку переполнения буфера в том же самом приложении более масштабным чем другое переполнение буфера иначе как демагогией на тему того, что она более масштабная потому что она более масштабная, и «другая» здесь не могут, так что наверное и не стоило задавать. Просто было интересно как такое может быть, на примере.
sebres Автор
Ну вот вам пример:
тоже делает переполнение буфера, но:
sprintf(buf, "%0*d", len, x);
уже несколько вкуснее, но опять не факт если влияние наlen
"снаружи" сильно ограничено или зависит от множества параметров);...
);x
ограничены алгоритмом сверху);x
);Ну и все в совокупности не делает из этой ошибки сразу же "дыру", даже потенциальную, даже в контексте оного единственного приложения (я уж не говорю про собственно реализацию эксплойта, тем более для "множества" приложений).
Magellan же — совсем не такой. Если все еще не понятно — просто поверьте.