Непонятная ситуация с 0-day эксплоитом и 27 уязвимостями в MySQL
10 февраля 2012 года
В конце января компания Oracle опубликовала сводный отчёт об узявимостях, устранённых в различных продуктах компании. В отчёте сообщалось, что в MySQL исправлено 27 уязвимостей. Информация в отчёте была предоставлена только в общем виде, не дающем судить о характере проблем. С момента публикации отчёта прошло уже несколько недель, но подробности так и не опубликованы.
В связи с подобным сокрытием информации производители Linux-дистрибутивов оказались в тупике, так как не ясно, какие исправления нужно бэкпортировать в поддерживаемые пакеты MySQL. Информация об уязвимостях ограничивается номером CVE, уровнем опасности, информацией по веткам MySQL и не несущим особого смысла однострочным описанием. Интересно, что подобный отчёт (Critical Patch Update) для MySQL выпускается в первый раз, поэтому непонятно, за какой период там собраны уязвимости (написано, что включена информация о всех уязвимостях, исправленных с момента прошлого отчёта, но загвоздка в том, что это первый отчёт). Тем не менее компания Red Hat вчера выпустила обновление для пакета mysql-5.1.61 из состава RHEL 6, в котором устранено 17 выявленных уязвимостей (Oracle заявляла об исправлении 27). Примечательно, что исправления для Oracle Linux полностью копируют обновление для RHEL без дополнительных правок.
Наиболее вероятно, что в отчёте Oracle опубликованы данные об уязвимостях, уже исправленных по мере выхода новых Community-выпусков MySQL. Как правило, в корректирующих выпусках устраняется несколько ошибок, позволяющих вызвать крах процесса посредством выполнения специально оформленного SQL-запроса. Общие данные в отчёте показывают, что большинство упомянутых уязвимостей имеют именно такой характер, т.е. позволяют инициировать крах СУБД через выполнение специально оформленного SQL-запроса аутентифицированным пользователем. Дополнительно одна DoS-уязвимость позволяет вызвать отказ в обслуживании неаутентифицированным пользователем, две уязвимости позволяют аутентифицированным пользователем получить доступ к закрытым данным, одна уязвимость позволяет локальному пользователю поднять свои привилегии.
Производители ответвлений от MySQL, таких как MariaDB, столкнулись (Архивная копия от 26 марта 2012 на Wayback Machine) с не меньшими трудностями: непонятно, проявляются ли данные уязвимости для их веток, связаны ли уязвимости с известными ошибками, уже исправленными в ходе обычного процесса исправления ошибок, или это принципиально новые проблемы. Попытки выяснить подробности у Oracle завершаются советом использовать самые свежие версии MySQL, в которых данные уязвимости уже исправлены (судя по всему, речь о MySQL Enterprise с последним Critical Patch Update).
Окончательная путаница возникла после появления неподтверждённого заявления об обнаружении в последнем выпуске MySQL 5.5.20 опасной 0-day уязвимости, позволяющей удалённо атаковать MySQL-серверы. Сообщается, что уже создан работающий эксплоит, который успешно работает при использовании на сервере пакета mysql-5.5.20-debian6.0-i686.deb с сайта mysql.com. Подтверждённой информации по данной уязвимости пока нет; также непонятно, новая это уязвимость или уязвимость из числа 27 проблем в списке Oracle.
Дополнение: за две недели официального ответа на вопрос в packagers@mysql также не поступило.
Источники
правитьЛюбой участник может оформить статью: добавить иллюстрации, викифицировать, заполнить шаблоны и добавить категории.
Любой редактор может снять этот шаблон после оформления и проверки.
Комментарии
Если вы хотите сообщить о проблеме в статье (например, фактическая ошибка и т. д.), пожалуйста, используйте обычную страницу обсуждения.
Комментарии на этой странице могут не соответствовать политике нейтральной точки зрения, однако, пожалуйста, придерживайтесь темы и попытайтесь избежать брани, оскорбительных или подстрекательных комментариев. Попробуйте написать такие комментарии, которые заставят задуматься, будут проницательными или спорными. Цивилизованная дискуссия и вежливый спор делают страницу комментариев дружелюбным местом. Пожалуйста, подумайте об этом.
Несколько советов по оформлению реплик:
- Новые темы начинайте, пожалуйста, снизу.
- Используйте символ звёздочки «*» в начале строки для начала новой темы. Далее пишите свой текст.
- Для ответа в начале строки укажите на одну звёздочку больше, чем в предыдущей реплике.
- Пожалуйста, подписывайте все свои сообщения, используя четыре тильды (~~~~). При предварительном просмотре и сохранении они будут автоматически заменены на ваше имя и дату.
Обращаем ваше внимание, что комментарии не предназначены для размещения ссылок на внешние ресурсы не по теме статьи, которые могут быть удалены или скрыты любым участником. Тем не менее, на странице комментариев вы можете сообщить о статьях в СМИ, которые ссылаются на эту заметку, а также о её обсуждении на сторонних ресурсах.