Магелланова ошибка: Buffer overrun или кругосветная экспедиция средствами SQLite FTS

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

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

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

        Готового эксплойта я по понятным причинам тут не дам… (пусть скрипт-киддис сами ищут)… Но если уметь читать исходники и взглянуть на тесты в фиксе, то многое становится понятнее при оценке «значимости». Про «масштабность» же — думаю и так должно быть понятно (например, вы слово WebSQL в тексте заметили? и с какого года оно было невыявлено?).
          –2
          По мне так выявленная дыра она или есть или её нет. То есть это бинарное состояние. Значимость — это уже исключительно приписываемое свойство, а не объективное.
            +1
            Во первых, важна не столько сама ошибка, сколько возможность использовать ее как средство «атаки», сложность создания эксплойта на предмет например «remote code execution» и иже с ним, повторяемость (или стабильность) этого вектора в живой системе, и собственно (если про масштабность) — распространенность функционала в контексте возможного применения ошибки.
            Во вторых, не каждая ошибка — есть сразу «дыра». О чем собственно и речь выше.
              0
              Сравниваются переполнения буфера. И почему-то одно переполнение буфера является более масштабным и значимым. Зря я в эту дискуссию влез, только карму себе порчу. Объяснить что именно делает одну ошибку переполнения буфера в том же самом приложении более масштабным чем другое переполнение буфера иначе как демагогией на тему того, что она более масштабная потому что она более масштабная, и «другая» здесь не могут, так что наверное и не стоило задавать. Просто было интересно как такое может быть, на примере.
                +1
                Просто было интересно как такое может быть, на примере.

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


                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 же — совсем не такой. Если все еще не понятно — просто поверьте.

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

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое