Исследователи из компании Check Point раскрыли (https://research.checkpoint.com/select-code_execution-from-u.../) на конференции DEF CON детали новой техники атак на приложения, использующие уязвимые версии SQLite. Метод Check Point рассматривает файлы с БД как возможность для интеграции сценариев эксплуатации уязвимостей в различных внутренних подсистемах SQLite, недоступных для эксплуатации в лоб. Исследователями также подготовлена техника эксплуатации уязвимостей с кодированием эксплоита в форме цепочки SELECT-запросов в БД SQLite, позволяющая обойти ASLR.
Для успешной атаки необходимо наличие возможности модификации файлов БД атакуемых приложений, что ограничивает метод атакой на приложения, использующие БД SQLite в качестве формата для транзитных и входных данных. Метод также может применяться для расширения уже полученного локального доступа, например, для интеграции скрытых бэкдоров в используемые приложения, а также для обхода исследователями безопасности механизмов защиты при анализе вредоносного ПО. Эксплуатация после подмены файла осуществляется в момент выполнения приложением первого SELECT-запроса к таблице в модифицированной БД.
В качестве примера продемонстрирована возможность запуска кода в iOS при открытии адресной книги, файл с БД "AddressBook.sqlitedb" которой был изменён с использованием предложенного метода. Для атаки использовалась уязвимость в функции fts3_tokenizer (CVE-2019-8602, возможность разыменования указателя), исправленная в апрельском обновлении SQLite 2.28, наряду с другой уязвимостью (https://www.opennet.dev/opennews/art.shtml?num=50658) в реализации оконных функций. Кроме того, продемонстрировано применение метода для удалённого захвата управления за написанным на PHP бэкенд-сервером злоумышленников, осуществляющим накопление паролей, перехваченных в ходе работы вредоносного кода (перехваченные пароли передавались в форме БД SQLite).Метод атаки основан на использовании двух техник "Query Hijacking" и "Query Oriented Programming", позволяющих эксплуатировать произвольные проблемы, приводящие к повреждению памяти в движке SQLite. Суть "Query Hijacking" в подмене содержимого поля "sql" в служебной таблице sqlite_master, определяющей структуру БД. Указанное поле содержит блок DDL (Data Definition Language), используемый для описания структуры объектов в БД. Описание задаётся с использованием штатного синтаксиса SQL, т.е. используется конструкция "CREATE TABEL",
которая выполняется в процессе инициализации БД (во время первого запуска
функции sqlite3LocateTable) для создания связанных с таблицей внутренних структур в памяти.
Идея в том, что, заменив "CREATE TABEL" на "CREATE VIEW" появляется возможность через определение своего представления контролировать любое обращение к БД. При помощи "CREATE VIEW" к таблице привязывается операция "SELECT", которая будет вызвана вместо "CREATE TABEL" и позволяет обращаться к различным частям интерпретатора SQLite. Далее самым простым способом атаки был бы вызов функции "load_extension", позволяющей загрузить произвольную библиотеку с расширением, но данная функция отключена по умолчанию.
Для совершения атаки в условиях возможности выполнения операции "SELECT" предложена техника "Query Oriented Programming", дающая возможность эксплуатировать проблемы в SQLite, приводящие к повреждению памяти. Техника напоминает возвратно-ориентированное программирование (ROP (https://www.opennet.dev/opennews/art.shtml?num=48730#rop), Return-Oriented Programming), но использует для построения цепочки вызовов ("гаджетов") не существующие отрывки машинного кода, а вставки в наборе подзапросов внутри SELECT.URL: https://research.checkpoint.com/select-code_execution-from-u.../
Новость: https://www.opennet.dev/opennews/art.shtml?num=51259
> приложения, использующие БД SQLite в качестве формата
> для транзитных и входных данных.кароче, "не будем говорить кто, хотя это был Слон...прекрасный браузер Чроме"
Иногда лучше жевать. Чроме уже давно использует свой велосипед https://github.com/google/leveldb для локального хранилища.
А, ну значит если ты пройдешь по этой ссылке, то получишь 404 Not Found.https://chromium.googlesource.com/chromium/src/+/refs/heads/...
Хорошая попытка гугл но нет.
Хаха тебя дурят по чем зря а ты и рад верить.
ну зачем же дурят? Действительно, используют наколенную поделку для "своих данных" (видимо, не все гуглообезьянки шмагли в полноценный sql), а
> в качестве формата
> для транзитных и входных данных.доступного через распрекрасный ненужно-sql-api - sqlite ;-)
> Для успешной атаки необходимо наличие возможности модификации файлов БД атакуемых приложенийА, ну значит пол-интернета будут атакованы. Доподлинно известно, что любой чувак с улицы может напрямую править БД-файлы практически 98.1854% приложений в интернете, в смартфонах других людей на той же или другой улице, или где-либо еще. (Процент получен научным путем.)
Нормальные интернет сервисы sqlite редко используют. А вот во встроенных приложениях sqlite много где используется.
И чего? Для эксплуатации нужен доступ к файлам SQLite.
Что характерно, нигде не сказано "непосредственный" или там "локальный" ;-)
> Что характерно, нигде не сказано "непосредственный" или там "локальный" ;-)Да, ещё нужно значение каждой буквы в каждом слове расписать. А то не поймут.
SQLite изначально пользуют там, где этот великий хакинг не вперся. Для хранения настроечек, да кеше
Для оскрытия присутствия самое то что нужно.
Ну вот сам и скрывай своё присутствие в пасьянсе или видеоплеере.
Я бы на ствоём месте после таких слов стал почаще проверять свой плеер и пасьянс...
да, веб-макакам middleware вообще плохо дается (см эпикфэйл забиксоидов, запутавшихся в двух процессах аж до порчи базы - хотя, казалось бы...)они предпочитают "контроллеры" и прочий шлак.
Короче, около 0.01% приложений, которые используют SQLite3 для импорта-экспорта. Ещё 1% серверов с криворукими девляпсами. К остальным настолько близко не подобраться.
да лана? Тут же ж даже не injection нужен (хотя и он сработает) а просто пописать в файл с базкой. Как будто это так сложно...
Ну попиши чего-нибудь сюда, например: https://mirror.yandex.ru/centos/7/updates/x86_64/repodata/65...
ну давай я попишу - а ты потом при установке обновлений от рута-то этот файлик и почитаешь, ага.и заметь - ни https, ни gpg подписи пакетов тебе уже не помогут.
"наличие возможности модификации файлов БД"Если вы получили root-доступ к системе - галактеко в опасносте.
Предпологаемое отсутствие возможности модификации лог-файлов Вас оставит в такой же безмятежности? А тут рассказывали рядом, как ещё на БЭСМ шутили над админами, хотя прямого доступа к логам вроде бы как не было.
Нормальная уязвимость, не понятно чего аноним нос воротит. Представьте что видеоплеер выполняет произвольный код при открытии специально подготовленного файла. Опасно? Вполне. Даже уже было несколько таких уязвимостей опубликовано.А теперь замените видеоплеер на некоторую программу, использующую sqlite. А видеофайл замените на файл базы данных. Получится то же самое. Вполне обоснованные опасения.
По схожим причинам я боюсь пользоваться pyspread - мало ли какого кода туда запихают, внутри ведь полноценный интерпретатор питона. Ну и org-mode-овские таблички тоже страшные, ибо туда можно произвольный elisp вставлять.
Из большого пока только yum виднеется.