Как-то обошли на Хабре недавнюю 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)


  1. rgrits
    18.12.2018 22:26

    Интересно, как измерялась «значимость» и «масштабность» этого переполнения буфера по сравнению с другими. Чем эта выявленная дыра масштабнее других переполнений(выявленных и невыявленных)?


    1. sebres Автор
      18.12.2018 22:51

      То было во первых — ИМХО (извиняюсь, если не понятно).

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

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


      1. rgrits
        18.12.2018 23:06
        -2

        По мне так выявленная дыра она или есть или её нет. То есть это бинарное состояние. Значимость — это уже исключительно приписываемое свойство, а не объективное.


        1. sebres Автор
          18.12.2018 23:19

          Во первых, важна не столько сама ошибка, сколько возможность использовать ее как средство «атаки», сложность создания эксплойта на предмет например «remote code execution» и иже с ним, повторяемость (или стабильность) этого вектора в живой системе, и собственно (если про масштабность) — распространенность функционала в контексте возможного применения ошибки.
          Во вторых, не каждая ошибка — есть сразу «дыра». О чем собственно и речь выше.


          1. rgrits
            18.12.2018 23:56

            Сравниваются переполнения буфера. И почему-то одно переполнение буфера является более масштабным и значимым. Зря я в эту дискуссию влез, только карму себе порчу. Объяснить что именно делает одну ошибку переполнения буфера в том же самом приложении более масштабным чем другое переполнение буфера иначе как демагогией на тему того, что она более масштабная потому что она более масштабная, и «другая» здесь не могут, так что наверное и не стоило задавать. Просто было интересно как такое может быть, на примере.


            1. sebres Автор
              19.12.2018 00:44

              Просто было интересно как такое может быть, на примере.

              Ну вот вам пример:


              char buf[5];
              sprintf(buf, "%0100d", x);
              ...

              тоже делает переполнение буфера, но:


              • понятно что на стеке, но возможно не очень (или не всегда) понятно, где конкретно (применимость потенциального инжекта может быть очень непрозрачна);
              • переполнение всегда постоянной длинны (100+1-5), т.е. нельзя этим "снаружи" управлять (например sprintf(buf, "%0*d", len, x); уже несколько вкуснее, но опять не факт если влияние на len "снаружи" сильно ограничено или зависит от множества параметров);
              • сильно зависит от того, что имеем после вызова (т.е. что там собственно под ...);
              • не вполне прозрачно, как конкретно это можно юзать напрямую, в контексте живой системы, если функция пользуется почем зря и/или "плавает" в стеке (или например значения x ограничены алгоритмом сверху);
              • переписывается что-нибудь очень нужное (без вариантов, например как здесь padding нулями до переменного значения x);
              • проблема окружения: если контекст спорадический (не регулярно или повторяемо), не всегда возможно влиять на это с изнанки, чтобы заставить что-то вообще (ну или в нужное время/в нужном месте) исполнить этот кусок кода;
              • или например высока вероятность что приложение поймает исключение (упадет в любом случае, но собственно remote code для RCE так и не удастся инжектировать);
              • прочие сложности и ограничения типа DEP (исполнять напрямую из стека нельзя), ASLR без возможности "вкусно" обойти, и т.д. (применимость инжекта может быть очень ограничена).

              Ну и все в совокупности не делает из этой ошибки сразу же "дыру", даже потенциальную, даже в контексте оного единственного приложения (я уж не говорю про собственно реализацию эксплойта, тем более для "множества" приложений).


              Magellan же — совсем не такой. Если все еще не понятно — просто поверьте.


  1. Beholder
    19.12.2018 12:36
    -1

    Ну продолжайте разрешать браузерам выполнять скрипты на любых произвольных сайтах…