The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Уязвимость в СУБД SQLite

09.05.2019 21:13

В СУБД SQLite выявлена уязвимость (CVE-2019-5018), позволяющая выполнить свой код в системе при наличии возможности выполнения SQL-запроса, подготовленного злоумышленником. Проблема вызвана ошибкой в реализации оконных функций и проявляется начиная с ветки SQLite 3.26. Уязвимость устранена в апрельском выпуске SQLite 3.28 без явного упоминания об исправлении проблем с безопасностью.

Специально оформленный SQL-запрос SELECT может привести к обращению к уже освобождённой области памяти (use-after-free), что может потенциально быть использовано для создания эксплоита для выполнения своего кода в контексте приложения, использующего SQLite. Уязвимость может быть эксплуатирована в случае если приложение допускает передачу в SQLite SQL-конструкций, поступающих извне.

Например, потенциально атака может быть совершена на браузер Chrome и приложения, использующие движок Chromium, так как API WebSQL реализован поверх SQLite и обращается к данной СУБД для обработки SQL-запросов из web-приложений. Для атаки достаточно создать страницу с вредоносным JavaScript-кодом и добиться чтобы пользователь открыл её в браузере на базе движка Chromium.

  1. Главная ссылка к новости (https://blog.talosintelligence...)
  2. OpenNews: Релиз СУБД SQLite 3.28
  3. OpenNews: Удалённо эксплуатируемая уязвимость в SQLite, затрагивающая браузеры на базе Chromium
  4. OpenNews: В рамках проекта LiteTree развивается вариант SQLite с поддержкой ветвления БД
  5. OpenNews: Релиз СУБД SQLite 3.25 с поддержкой оконных функций
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/50658-sqlite
Ключевые слова: sqlite
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (32) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, OpenEcho (?), 21:32, 09/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    DROP Chromium WHERE WebSQL NOT NULL;
    COMMIT;

     
     
  • 2.3, пох (?), 21:54, 09/05/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ну и зачем ты все испортил? Я ж уже 2 монеры намайнил!
     
  • 2.17, Аноне (?), 08:58, 10/05/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Не поможет. Drop удаляет объект безусловно и коммит не нужен. И IS not null
     
     
  • 3.22, OpenEcho (?), 14:12, 10/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ну тогда мы нашли еще один баг, потому как

    SELECT 'true' WHERE 1 NOT NULL;

    вернет 'true' без ошибок ;)

     
     
  • 4.24, . (?), 16:53, 10/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    это не баг, это фича simplified syntax, кажется, даже где-то описанная.

    а вот комит после дропа не нужен, да и синтаксически неверно, наверное, имелось в виду delete.

     
     
  • 5.26, OpenEcho (?), 19:56, 10/05/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Да блин, вы правда не понимаете что должно было бы стоять вместо COMMIT если бы не модерация?
    ArticFox;  -- так пойдет ?
     

  • 1.2, Аноним (2), 21:45, 09/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –15 +/
    Весьма типичная проблема устаревших языков, к сожалению.
     
     
  • 2.5, конь в пальто (?), 21:54, 09/05/2019 [^] [^^] [^^^] [ответить]  
  • +15 +/
    весьма типичный комментарий юных падаванов
     
     
  • 3.10, trdm (ok), 23:51, 09/05/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Анонимное комментирование и отсутствие бан-листа - зло и неудобство.
    Надо опеннету подтягиваться к тренду.
     
     
  • 4.19, Аноним (-), 10:22, 10/05/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да, надо как в Белоруссии. Ишь, воду баламутят.
     
     
  • 5.29, Иваныч (??), 23:13, 10/05/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Беларусь, Беларуси.
     
  • 2.25, Аноним (25), 16:58, 10/05/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    SQL тебя переживет еще
     

  • 1.4, mumu (ok), 21:54, 09/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > Например, потенциально атака может быть совершена на браузер Chrome и приложения, использующие движок Chromium

    Firefox тоже активнео использует SQLIte. Кто скажет, там это воспроизводится?

     
     
  • 2.6, пох (?), 21:58, 09/05/2019 [^] [^^] [^^^] [ответить]  
  • –5 +/
    там понадобится вторая уязвимость, которую тебе, о йуный друг, еще предстоит найти.
    потому что в отличие от гуглоподелки, sqlite там используется, а не использует твой компьютер по желанию вебмакаки.

    но это, конечно, ненадолго - только пока ютруп, факбук и гитхап не перешли на новый стандарт.

     
     
  • 3.8, 1 (??), 23:09, 09/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >новый стандарт.

    Точно новый?
    >W3C Working Group Note 18 November 2010
    >Beware. This specification is no longer in active maintenance and the Web Applications Working Group does not intend to maintain it further.

     
     
  • 4.23, анонн (?), 14:43, 10/05/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >>новый стандарт.
    > Точно новый?
    >>W3C Working Group Note 18 November 2010

    В старом, догугловском стандарте его так и нет. А новый стандарт - это Гугл, если что. В ФФ, старом Edge и так далее, этот websql так и не появился.
    Так что все правильно.

     
  • 2.11, Аноним (11), 00:24, 10/05/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Проще сказать где SQLite не используется. Он везде. От телефонов до ПК
     

  • 1.7, kai3341 (ok), 22:54, 09/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Специально оформленный SQL-запрос SELECT может привести к обращению к уже освобождённой области памяти

    Это в принципе нетипичная ситуация, когда сторонний 'исследователь безопасности' получает контроль над БД. Так как самое важное обычно хранится в БД и если БД слита, то всё остальное уже как-то без разницы. Я к тому, что для получения контроля над БД в приложении должна быть ещё одна критическая уязвимость

     
     
  • 2.14, Аноним (14), 03:45, 10/05/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    В Chromium любой сайт может выполнять запросы к его внутренней SQLite DB.
     
     
  • 3.15, kai3341 (ok), 04:06, 10/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    В поисках пруфов нарвался на игрушку https://github.com/kripken/sql.js

    hint: ещё пару лет назад sqlite в chromium была задепрекейчена. У меня большие сомнения, что оно работает, поэтому было бы неплохо привести пруф

     
     
  • 4.21, Аноним84701 (ok), 12:56, 10/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > hint: ещё пару лет назад sqlite в chromium была задепрекейчена. У меня
    > большие сомнения, что оно работает, поэтому было бы неплохо привести пруф

    https://caniuse.com/sql-storage
    Подойдет?

     

  • 1.9, th3m3 (ok), 23:20, 09/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Получается, что и всякое УГ на Электроне, тоже в зоне риска.
     
     
  • 2.13, ................. (?), 03:28, 10/05/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Net.
     
  • 2.18, JL2001 (ok), 09:57, 10/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Получается, что и всякое УГ на Электроне, тоже в зоне риска.

    это приложение на электрона должно обрабатывать внешний сторонний "sql-запрос", а это таки редкость

     
     
  • 3.20, пох (?), 10:25, 10/05/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> Получается, что и всякое УГ на Электроне, тоже в зоне риска.
    > это приложение на электрона должно обрабатывать внешний сторонний "sql-запрос"

    в том и дело что нет, не должно - достаточно неудачно обработать внешний сторонний js код, а запросов он тебе сам понаделает.
    насколько это вот редкость - вопрос отдельно интересный. чота мне кажется, что если бы не нахрен ненужность неуловимых джо на эшелоне, такого бы нашли тыщи.

    но пока явно надо бояцца не этого, а в интернетиках непосредственно браузером что-нить не побраузить с прекрасным и полезным апи.

     

  • 1.27, Kuromi (ok), 22:38, 10/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    "Например, потенциально атака может быть совершена на браузер Chrome и приложения, использующие движок Chromium, так как API WebSQL реализован поверх SQLite и обращается к данной СУБД для обработки SQL-запросов из web-приложений. Для атаки достаточно создать страницу с вредоносным JavaScript-кодом и добиться чтобы пользователь открыл её в браузере на базе движка Chromium."
    Тот самый WebSQL который не был признан никем кроме Хрома, исключен из стандартов и не поддерживается нигде больше? Тот самый который Гугл почему-то упорно не убирает и который уже не первый раз бьет их по макушке?
    Странный Гугл...
     
     
  • 2.30, OpenEcho (?), 12:13, 12/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Тот самый WebSQL который не был признан никем кроме Хрома, исключен из
    > стандартов и не поддерживается нигде больше? Тот самый который Гугл почему-то
    > упорно не убирает и который уже не первый раз бьет их
    > по макушке?

    вообщето если быть обьективным то WebSQL самый удобный по сравнению с LocalStorage & IndexedDB, нормальный гибкий SQL язык позволяющий сложную бизнес логику и простоту использования в JS.
    А на счет баги в SQLite, так не ошибается только тот, кто ничего не делает. Код там очень даже профессиональный.

    Винить надо рукожопых JS-девелоперов позволяющих использовать даные от юзера без валидации:

    >"Уязвимость может быть эксплуатирована в случае если __приложение__
    > допускает передачу в SQLite SQL-конструкций, поступающих извне. "

    а это относится к любым ЯП


     
     
  • 3.31, Аноним84701 (ok), 13:20, 12/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Винить надо рукожопых JS-девелоперов позволяющих использовать даные от юзера без валидации:
    >>"Уязвимость может быть эксплуатирована в случае если __приложение__
    >> допускает передачу в SQLite SQL-конструкций, поступающих извне. "
    > а это относится к любым ЯП

    Эта процитированная часть относится к приложениям, использующим SQLite.
    Например, в том числе и Chrome, в котором есть WebSQL, принимающий SQL-конструкции извне .
    > Для атаки достаточно создать страницу с вредоносным JavaScript-кодом и добиться чтобы пользователь открыл её в браузере на базе движка Chromium.

     
     
  • 4.32, OpenEcho (?), 15:58, 12/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >> Для атаки достаточно создать страницу с вредоносным JavaScript-кодом и добиться чтобы пользователь открыл её в браузере на базе движка Chromium.

    То, что баг может использоваться специально, - это понятно что не есть хорошо. Я отвечал по поводу WebSQL технологии в принципе.

     

  • 1.28, Kuromi (ok), 22:40, 10/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    "Для атаки достаточно создать страницу с вредоносным JavaScript-кодом и добиться чтобы пользователь открыл её в браузере на базе движка Chromium."

    С учетмо нынешней доли Хрома и ему подобных среди браузеров можно сказать  что достаточно открыть её у почти любого пользователя.

     
     
  • 2.33, пох (?), 21:52, 12/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    а для извращенцев предусмотреть огромный баннер "этот сайт работает только в хроме, хроме и хроме последней версии". Сами и запустят что надо.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру