Comments 11
Оказывается об этой проблеме говорили в сообществе MariaDB в 2022 году здесь
По ссылке:
Баг создан в 2020, говорить о нем начали в 2021, к обсуждению конкретных деталей перешли в 2022, потом все опять замерло до 2024. Забавно на этом фоне выглядит текст новости
The problem we were solving, and for various reasons we had to do it very quickly, is that it is possible to generate a malicious MariaDB dump file which could execute shell commands from the MariaDB client.
Да меня тоже этот факт поразил. Год поправлю.
Там комбинация разных ситуаций и тикетов.
юзеры просили "sandbox mode", это как раз и есть MDEV-21778, чтобы можно было ставить mariadb как login shell и чтоб можно было давать
sudo mariadbне давая полный рут шелл. Это старый тикет, там ничего срочного не было, просто фичу просилиmariadb-dump доверял серверу и писал его ответы в дамп, без проверок и валидации. Таким образом в дамп могли попасть команды, если плохой сервер их туда подсунет. Это MDEV-33727 — вот он новый и был новый
Оракл выпускает новый релиз MySQL в котором он фиксит CVE-2024-21096
В результате нам (MariaDB) тоже пришлось срочно это дело закрывать и мы закрыли его через sandbox mode, заодно закрыв и первый тикет.
Можете вообще про эту историю подробнее рассказать, как разработчик? И я правильно понимаю, что на shared хостингах можно было иметь доступ к файлам остальных пользователям, например из-за этой уязвимости?
Все зависит от конфигурации и разрешений, которые дает shared хостинг своим пользователям. Учитывая что на многих хостингах до сих пор еще стоит MySQL 5.7 – думаю нас ждет множество взломов по типу 1gb и reg ru
Про что рассказать, в чём дыра? Это уже не секрет, вот, Оракл демонстрирует: https://github.com/mysql/mysql-server/commit/f351ea92a5a0
Вкратце, суть в том, что если у плохиша есть полный контроль над сервером или он может делать MitM (потому что SSL не включён или сертификаты не проверяются), то он может подсовывать в дамп разные команды. Потому что mariadb-dump/mysqldump не проверяет, что ему приходит. И тогда если кто-то этот дамп потом прочтём mysql клиентом, то команды выполнятся.
Это довольно маловероятный сценарий, в котором юзер не доверяет своему серверу. Но теоретически возможный.
На shared хостингах — нет, только если получить полный контроль над базой данных других пользователей. Но тогда как бы доступ ко всем данным и так есть.
Ну, почти такая же...
не в докере?!!!) ну тогда все понятно.
слушайте, мне очень нравится докер, как удобная система упаковки софта, но во-первых, он всё же не серебряная пуля, а во-вторых, БД-в-докере уместна далеко не всегда.
привет. ну "упаковка софта" -- не совсем то, о чем я говорю. для разработки, имхо, докер это в первую очередь "воспроизводимое окружение". поэтому, в самом начале статьи, мне действительно _стало понятно_, что это так или иначе, проблема конфигураций.. (далее все увлекательно и я дочитал даже, но интрига "как починить" для меня была раскрыта)) об этом и была шутка! (но, кажется, меня не все поняли).
а, вообще, я и правда считаю контейнеризацию одной из "серебрянных пуль" современной разработки. что же касается бд прода -- то, наверное, тогда уж managed (опять же в воспроизводимой среде).
Спасибо!
Сегодня столкнулись с тем что импорт вдруг внезапно сломался.
Благодаря тому что читал вашу статью, вспомнил, быстро починили.
Как MariaDB поломали экспорт (ERROR at line 1: Unknown command "-") или 17 лет небезопасному MySQL клиенту