Участник международного движения Legal Hackers Давид Голунский (Dawid Golunski) опубликовал подробности и PoC-эксплойт критической бреши в СУБД MySQL, уже залатанной некоторыми вендорами, но не самой Oracle. Согласно информационному бюллетеню, данную уязвимость можно использовать как локально, так и удаленно; она открывает доступ к базе данных и позволяет исполнить произвольный код.

Проблема затрагивает MySQL сборок 5.7.15, 5.6.33 и 5.5.52. Патчи выпущены для производных продуктов MariaDB и PerconaDB. По словам Голунского, он разослал уведомления Oracle и заинтересованным вендорам еще 29 июля. К концу августа MariaDB и PerconaDB были пропатчены, и, выждав 40 дней после рапорта, исследователь решился на публичное раскрытие.

«Поскольку с момента подачи отчетов прошло 40 дней, соответствующие патчи уже опубликованы, поэтому было принято решение о раскрытии уязвимости (и неполного PoC), чтобы проинформировать пользователей о рисках, прежде чем вендор обновит ЦП, что случится лишь в конце октября, — пишет Голунский в бюллетене. — На настоящий момент официальный патч от вендора или какие-либо исправления отсутствуют. В качестве временной меры пользователям следует убедиться, что владельцем файла конфигурации MySQL является пользователь MySQL, и создать неиспользуемые пустые файлы my.cnf, доступные с правами root. Это далеко не полное решение, и пользователям нужно будет обязательно установить официальный патч, когда он появится».

Комментировать сообщение Голунского Oracle отказалась. Очередной квартальный выпуск патчей компания запланировала на 18 октября; предыдущий состоялся в июле и оказался рекордным по количеству устраненных уязвимостей — 276.

По свидетельству Голунского, уязвимость CVE-2016-6662, о которой идет речь, допускает эксплойт путем внедрения SQL-кода. При наличии действительных идентификаторов можно также, к примеру, эксплуатировать ее локально или через веб — к примеру, с помощью инструмента администрирования phpMyAdmin.  «Успешный эксплойт позволит исполнить произвольный код с правами root, что, в свою очередь, открывает возможность для полной компрометации сервера, на котором работает уязвимая версия MySQL», — отметил Голунский.

Исследователь также предостерег, что использовать данную уязвимость можно даже в том случае, когда на сервере активирован модуль контроля доступа SELinux или AppArmor.

В наличии бреши повинен mysqld_safe — скрипт-обертка, который входит в дефолтный пакет MySQL и используется для запуска сервисного процесса. Этот скрипт исполняется с правами root, и основной процесс mysqld понижает его привилегии до уровня пользователя MySQL, как пояснил исследователь. Функционал mysqld_safe среди прочего позволяет до запуска сервера загрузить библиотеку общего пользования. «Если атакующему удастся внедрить путь к вредоносной библиотеке в файл конфигурации, он сможет инициировать загрузку любой библиотеки и, таким образом, исполнить произвольный код с правами root при перезапуске службы MySQL (вручную, через системный апдейт, обновление пакета, перезапуск системы и т.п.)», — предупреждает Голунский.

Аналогичная уязвимость в MySQL была пропатчена в 2003 году, однако, по свидетельству Голунского, атаки на найденную им брешь позволяют обойти ограничения, введенные 13 лет назад, — через манипуляции с функциями записи в лог, доступными по умолчанию. Автор атаки сможет внедрить вредоносный конфигурационный файл, создать новые my.cnf в директории с данными MySQL или получить доступ на запись, обычно требующий прав администратора.

Исследователь также отметил, что еще одна связанная с его находкой брешь, CVE-2016-6663, сильно упрощает эксплуатацию. «В некоторых случаях еще не раскрытая уязвимость облегчает создание файла /var/lib/mysql/my.cnf с произвольным содержимым, и прав FILE при этом не требуется», — пишет Голунский в бюллетене, добавляя, что эта брешь позволит атакующему повысить привилегии до уровня root.

Категории: Аналитика, Главное, Уязвимости