The OpenNET Project / Index page

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

Критическая root-уязвимость в MySQL

12.09.2016 17:39

Опубликованы сведения о критической уязвимости (CVE-2016-6662) в MySQL и производных продуктах, таких как MariaDB и Percona Server. Уязвимость позволяет локально или удалённо атаковать сервер MySQL и повысить свои привилегии до пользователя root.

Смягчает опасность то, что для эксплуатации требуется аутентифицированный доступ к БД или проведение дополнительной атаки на web-приложения, в результате которой необходимо получить возможность подстановки SQL-кода. Усугубляет проблему то, что опубликован начальный прототип эксплоита (полный эксплоит планируется опубликовать позднее, дав время на выпуск обновления), в то время как сама уязвимость проявляется во всех ветках MySQL. Проблема устранена в выпусках MySQL 5.7.15, 5.6.33 и 5.5.52, а также в MariaDB 10.0.27 и Percona Server 5.7.14-7. Обновления пакетов с прошлыми версиями mysql/mariadb в дистрибутивах пока не выпущены (Ubuntu, Debian, RHEL, FreeBSD, CentOS, Fedora, SUSE). Применяемые по умолчанию правила SELinux и AppArmor не влияют на результаты атаки.

Сама по себе выявленная уязвимость позволяет любому пользователю СУБД с правами на выполнение операций SELECT/FILE (без прав FILE можно обойтись, но информация об обходе будет опубликована позднее под CVE-2016-6663) получить доступ к функциям работы с логами, которые должны быть доступны только пользователю admin. Через манипуляции с функциями записи в лог атакующий может изменить или создать файл конфигурации my.cnf. Если для файла my.cnf запрещена запись от пользователя mysql, то атакующий может создать новый файл в директории с данными (/var/lib/mysql), которая по умолчанию допускает запись для пользователя mysql.

Возможность выполнения кода с правами root достигается через добавление к конфигурации конструкции, загружающей подставную библиотеку при очередном перезапуске mysql. В частности, процесс mysqld работает от непривилегированного пользователя, но при запуске используется скрипт mysqld_safe с правами root. В mysqld_safe среди прочего можно загрузить альтернативную библиотеку с реализацией функций malloc. Имя библиотеки передаётся через параметр "malloc_lib/--malloc-lib=LIB", который может быть определён в секциях '[mysqld]' и '[mysqld_safe]' файла конфигурации my.cnf. Таким образом, атакующий, имеющий возможность записи в my.cnf, может инициировать загрузку любой библиотеки с правами root.

Интересно, что атака через правку my.cnf не нова и в 2003 году уже исправлялась в выпуске 3.23.55 (эксплуатация сводилась к выполнению "SELECT * INFO OUTFILE '/var/lib/mysql/my.cnf'). Новая атака позволяет использовать функции записи в лог, например: "set global general_log_file = '/var/lib/mysql/my.cnf'; set global general_log = on; select 'malloc_lib=/var/lib/mysql/mysql_hookandroot_lib.so'; set global general_log = off;".

  1. Главная ссылка к новости (http://openwall.com/lists/oss-...)
Лицензия: CC-BY
Тип: Проблемы безопасности
Короткая ссылка: https://opennet.ru/45127-mysql
Ключевые слова: mysql
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (80) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 17:54, 12/09/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    ах-ах-ах...ужас, ужас.

    Мысль о touch /var/lib/mysql/my.cnf && chattr +i /var/lib/mysql/my.cnf
    видимо слишком сложна для нагнетателей паники.
    (вроде бы это единственное место, где можно создать такой файл не от рута, и чтобы при этом он был прочитан хоть каким-то процессом, связанным с mysql)

    Второй вариант, понятно, выкинуть совершенно ненужный функционал из mysqld_safe, но лично мне не нравится сама идея что кто-то может что-то записать в конфиги, даже неиспользуемые.

    Правда, следующей идеей будет нагадить не в my.cnf, а в базу mysql.

     
     
  • 2.37, Аноним (-), 10:24, 13/09/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Я воспользовался четвертым вариантом и выкинул MySQL.
     
  • 2.76, gogo (?), 00:15, 14/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Как временный вариант, до выходы полноценного патча, это в принципе должно работать.

    Какая ирония судьбы, что такая дыра именно в mysql_SAFE

     
     
  • 3.77, gogo (?), 00:19, 14/09/2016 [^] [^^] [^^^] [ответить]  
  • +4 +/
    И, между прочем, классический случай наказания за нарушение unix-way - сделали прокладку для запуска демона и получили дырку.... ; )
     
     
  • 4.82, Аноним (-), 02:02, 14/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > И, между прочем, классический случай наказания за нарушение unix-way - сделали прокладку
    > для запуска демона и получили дырку.... ; )

    програмеры на шелле те еще безопасники, особенно забавно выглядит led который называется security officer аж.

     

  • 1.2, Ilya Indigo (ok), 18:06, 12/09/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > По сведению разработчиков SUSE проблема уже исправлена в MariaDB 10.0.27...

    Так какого чёрта в репах у них до сих пор 10.0.22?
    Вот теперь у меня уже подгорает.
    Хотя, порт 3306 закрыт, учётки только локальные, включая Гранта, а пользователь рут вообще отсутствует.
    Тут, скорее наоборот подфортило, что наконец-то её обновят в репах, уже не отвертятся.
    Хотя если бы они просто обновляли вовремя пакеты, как во всех нормальных ролингах, они бы вообще этой уязвимости подвержены не были бы.

     
     
  • 2.5, Ян Злобин (ok), 18:48, 12/09/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Так какого чёрта в репах у них до сих пор 10.0.22?

    10.0.26 в репах
    http://software.opensuse.org/package/mariadb

     
     
  • 3.6, Ilya Indigo (ok), 18:53, 12/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    openSUSE Tumbleweed
    официальный выпуск

        5.5.29
    И битая ссылка на загрузку, так как информация уже года 2 там не обновляется.

     
     
  • 4.59, Ян Злобин (ok), 14:44, 13/09/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > openSUSE Tumbleweed
    > официальный выпуск
    >     5.5.29
    > И битая ссылка на загрузку, так как информация уже года 2 там
    > не обновляется.

    Вот, что вижу я:
    http://yan.zlobin.name/files/software.opensuse.org.png

     
  • 2.19, rt (??), 22:29, 12/09/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Вот теперь у меня уже подгорает.

    :> /var/lib/mysql/my.cnf && chattr +i /var/lib/mysql/my.cnf

    Не благодари.

     
  • 2.23, KM (?), 02:54, 13/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    До Кристины достучались?
     
     
  • 3.31, Ilya Indigo (ok), 08:27, 13/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > До Кристины достучались?

    Вот интересный вопрос. В принципе, да. Я подумал, что она русская, исходя из её русского имени и фамилии, написал ей прямо по-русски, за исключением фразы на английском, что если она не понимает, я переведу ей.
    Вчера мне она ответила и написала, что она Чежка. Вот так от, пришлось переформулировать, что бы я это смог выразить на английском, и ей снова написал на английском.
    И тут спустя несколько часов, я читаю эту новость. XD
    Думаю, Просто пророческое письмо. Если ответит сама, или даст контакты людей, которые уполномочены на это ответить, сообщу.

     
     
  • 4.33, KM (?), 09:25, 13/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Я полагаю, она и сама в курсе: https://bugzilla.novell.com/show_bug.cgi?id=CVE-2016-6662
     
     
  • 5.42, Ilya Indigo (ok), 10:46, 13/09/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Я полагаю, она и сама в курсе: https://bugzilla.novell.com/show_bug.cgi?id=CVE-2016-6662

    Но если даже опеннет в курсе, то я и не сомневался что она в курсе тоже. :-)
    Но я бы хотел быть в курсе с причинами запоздалых обновлений.

     
     
  • 6.67, KM (?), 17:36, 13/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    А по запоздалым обновлением она просветила вопрос? Ибо уже и самому интересно...
     
     
  • 7.69, Ilya Indigo (ok), 17:48, 13/09/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > А по запоздалым обновлением она просветила вопрос? Ибо уже и самому интересно...

    Пока только написала, что запрос на перевод на ветку 10.1 уже был произведён, но был отклонён из-за "some troubles", что она только вышла из отпуска и займётся сейчас этим и вскоре mariadb перейдёт на ветку 10.1.
    Про что за "some troubles", где их можно посмотреть, про причину запоздалых обновлений (ну не 11 месяцев из 12 у неё же отпуск), и про не обновляющийся раздел Tumbleweed на software.opensuse.org, пока ещё не ответила.

     
     
  • 8.72, KM (?), 21:37, 13/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Важно уже то, что появился обратный отклик и что не приходится гадать и строить ... текст свёрнут, показать
     
     
  • 9.92, Ilya Indigo (ok), 17:09, 14/09/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Thank you for your email I m out of the office and will be back at 2016-09-19 ... текст свёрнут, показать
     
  • 9.95, Ilya Indigo (ok), 14:48, 15/09/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    You can see the declined request here 0 I have to say that I was quite busy f... большой текст свёрнут, показать
     
  • 2.89, Нет (?), 14:53, 14/09/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ПодфАртило. От слова "фарт", а не от слова "форт". Повезло, а не укрепило.
    В нагрузку, на всякий случай - "симпАтичный".
     
     
  • 3.90, Ilya Indigo (ok), 15:05, 14/09/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Благодарю, запомню.
     

  • 1.11, Аноним (-), 21:08, 12/09/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +8 +/
    PostgreSQL решает проблему.
     
     
  • 2.22, А (??), 00:53, 13/09/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Привнося массу своих.

    https://eng.uber.com/mysql-migration/

    Но Postgres - хорошая школа )

     
     
  • 3.24, Аноним (-), 04:23, 13/09/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Хорошая школа - простой NoSQL. Который не умеет в произвольные файлы записывать, так что и ломать не получится.
     
     
  • 4.26, Аноним (-), 04:31, 13/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    А postgresql и не умеет, если специальными плагинами не обвеситься.
     
     
  • 5.48, 1 (??), 12:31, 13/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    COPY (SELECT 'asdf') TO '/tmp/asdf.txt';
    https://www.postgresql.org/docs/current/static/sql-copy.html
     
     
  • 6.55, Аноним (-), 13:40, 13/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    И правда. Тьфу на них!
     
  • 4.28, Лютый жабист_ (?), 05:02, 13/09/2016 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Хорошая школа - простой NoSQL

    Для информации NoSQL расшифровывается как not only SQL. И по фичам та же Монга обруливает Мускуля огого как. ;)

     
     
  • 5.32, Аноним (-), 08:39, 13/09/2016 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Ровно до той поры, пока не нужна консистентность данных и сложные выборки. И жрёт оно на порядок больше.
     
  • 5.56, Аноним (-), 13:50, 13/09/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Единственная прям фича монги - это шардинг из коробки.

    Выбор же btree для документно-ориентированной базы данных - это довольно глупо. В типичном сценарии с документами большинство полей опциональны. Если рассматривать сценарий с одним сервером, postgresql с таблицами вида (id serial PK, doc jsonb) с gin/gist-индексами порвет монгу как тузик грелку.

    Набор сценариев, когда монга - хороший выбор, очень и очень невелик. Большинство так называемых разработчиков, выбирающих монгу, используют ее без какого-либо понимания - просто потому что mongodb is web scale. If /dev/null is fast in web scale I will use it. Is it web scale?

     
  • 5.60, Аноним (-), 16:00, 13/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Для информации NoSQL расшифровывается как not only SQL. И по фичам та
    > же Монга обруливает Мускуля огого как. ;)

    так не надо пользоваться программами от жабистов-апачистов, не могут они в безопасность. сказано же - ПРОСТОЙ NoSQL. иди поломай базу key-value, я хочу посмотреть как это выглядеть будет. а если ты хотел хуяк-хуяк и в продакшн, тебе и будут сервера рутать и тебя не жалко.

     
  • 4.34, Аноним (-), 09:49, 13/09/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    только лучший NoSQL - это тоже PostgreSQL :)
     
  • 4.38, angra (ok), 10:25, 13/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Скажи честно, NoSQL ты видел толко на картинке? Или ты говоришь о некой конкретной(возможно даже воображаемой) NoSQL, которая не умеет писать в произвольные файлы?
     
     
  • 5.51, Аноним (-), 13:18, 13/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Ага. DBF :)
     
  • 5.66, Аноним (-), 17:24, 13/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Скажи честно, NoSQL ты видел толко на картинке?

    я еще и пользуюсь внаглую несколькими видами баз key-value и желаю удачи тебе и твоему дружку жабисту порутать это.

     
     
  • 6.87, angra (ok), 06:36, 14/09/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Но их названия ты конечно не скажешь. А то вдруг тебе покажут, как они могут писать в произвольный файл, обидно будет. Но даже, если они не такие, то существуют другие NoSQL, например Redis, которые это умеют и эта возможность использовалась для взлома. Мне вообще интересно, какая в твоей голове связь между SQL/NoSQL и возможностью писать в файлы.
     
  • 4.44, ueueue (?), 12:12, 13/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Такой как redis? :) Понятно, что дело было не в бобине, и тем не менее.
     
  • 3.25, Аноним (-), 04:29, 13/09/2016 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Если внимательнее прочитать, то понятно, что это всё не абсолютные преимущества или недостатки, а особенности реализации, имеющие свои плюсы и минусы в разных сценариях использования. Причем описаны исключительно общеизвестные, задокументированные вещи. Уберу стоило бы разобраться в том, как работает используемая СУБД, при проектировании системы, а не когда все начало становиться раком.
     
     
  • 4.41, angra (ok), 10:30, 13/09/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Неужто в документации сразу пишут об еще не обнаруженных багах? А может там пишут: "Репликацию мы сделали чисто для галочки, не используйте ее в продакшене, если вам дорог трафик" или "Забудьте про апгрейды в продакшене, если только вы не можете себе позволить пару часов даунтайма".

     
     
  • 5.45, Аноним (-), 12:18, 13/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Неужто в документации сразу пишут об еще не обнаруженных багах

    Это вы так жестоко про MySQL?

    Килотонны багов на https://bugs.mysql.com/

     
     
  • 6.49, angra (ok), 13:01, 13/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, не про мускул, не про постгрес и даже не про их сравнение по забагованности. Чтобы понять о чем речь, придется для начал прочитать очень много английских букв по приведенной выше ссылке. Справишься?
     
  • 5.50, Аноним (-), 13:09, 13/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    ну у ребят из skype как то же получилось прочитать документацию :)
     
  • 5.54, Аноним (-), 13:36, 13/09/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Репликацию сделали нормальную физическую Физическая репликация потребляет трафи... большой текст свёрнут, показать
     
     
  • 6.57, angra (ok), 14:29, 13/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Какие критерии нормальности Сразу начинаем с демагогии Хороший старт Любая р... большой текст свёрнут, показать
     
     
  • 7.93, Другой Аноним (?), 08:37, 15/09/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Мы не о настоящем говорим, а о прошлом, WAL decoder уже есть - pglogical, даже в... большой текст свёрнут, показать
     
  • 6.85, Аноним (-), 02:14, 14/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Репликацию сделали нормальную физическую. Физическая репликация потребляет трафик, да,
    > тоже мне новость.

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

     
     
  • 7.94, Другой Аноним (?), 09:01, 15/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >> Репликацию сделали нормальную физическую. Физическая репликация потребляет трафик, да,
    >> тоже мне новость.
    > большие объемы траффика стоят много денег, поэтому если проект взлетает - потребление
    > траффика начинает сильно бить по кошельку.

    физическая репликация надежнее. если у тебя пара серваков например с биллингом, в одной стойке - то разумный выбор физическая репликация. вполне логично что ее сделали сначала ее потом логическую.

     

  • 1.12, Аноним (-), 21:14, 12/09/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    И что, selinux в нормальных дистрибутивах не спасёт? Политиками разрешена запись в my.cnf?
     
     
  • 2.13, Аноним (-), 21:37, 12/09/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Скажу больше, selinux из коробки вообще не спасает.
    Только создает видимость безопасности с препятствиями.
     
  • 2.64, Shichael Migorin (?), 16:42, 13/09/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    В нормальных дистрибутивах (например в альтлинукс) нет selinux.
     

  • 1.18, LinuxID (ok), 22:28, 12/09/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    dev-db/mysql-5.6.31:0/18::gentoo
    dev-db/mariadb-10.0.26:0/18::gentoo
    Ждемс обновдений!
     
  • 1.21, stalker37 (ok), 23:05, 12/09/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    В перконе уже пофиксили.
     
     
  • 2.29, Христофор (?), 05:58, 13/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Где в перконе пофиксили ? в репо 5.6.32.... а надо 5.6.33
    Или я не прав?
     
     
  • 3.47, stalker37 (ok), 12:22, 13/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    This is a CRITICAL update, and the fix mitigates the potential for remote root code execution. We have added a fix for CVE-2016-6662 in the following releases:

        Percona Server 5.5.51-38.1
        Percona Server 5.6.32-78.0
        Percona Server 5.7.14-7

     

  • 1.27, Аноним (-), 04:49, 13/09/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    В марие пофиксили с третьей попытки. :)

    1) https://github.com/MariaDB/server/commit/470f259
    2) \0, хехе https://github.com/MariaDB/server/commit/2a54a53
    3) про венду вспомнили https://github.com/MariaDB/server/commit/0098d78

    Костыли, конечно, те еще.

     
  • 1.36, Аноним (-), 10:12, 13/09/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Гмм...получается MariaDB 10.1 не уязвима?
     
     
  • 2.40, Аноним (-), 10:28, 13/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Гмм...получается MariaDB 10.1 не уязвима?

    Да похоже это не LTS

     

  • 1.43, ALex_hha (ok), 11:20, 13/09/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Может кто-нибудь объяснить как подразумевается использовать эту уязвимость? Либо вот тут - "для эксплуатации требуется аутентифицированный доступ к БД" они что то не договаривают, ибо просто доступа к БД недостаточно. Так как, например, set global general_log_file требует SUPER privilege, а откуда они возьмутся у обычного пользователя?
     
     
  • 2.46, Аноним (-), 12:19, 13/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Может кто-нибудь объяснить как подразумевается использовать эту уязвимость? Либо вот тут
    > - "для эксплуатации требуется аутентифицированный доступ к БД" они что то
    > не договаривают, ибо просто доступа к БД недостаточно. Так как, например,
    > set global general_log_file требует SUPER privilege, а откуда они возьмутся у
    > обычного пользователя?

    Всякие движки ставят с правами SUPER privilege и оно это деплоит, это не под строгий проект.

     
     
  • 3.84, Аноним (-), 02:11, 14/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Всякие движки ставят с правами SUPER privilege и оно это деплоит, это
    > не под строгий проект.

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

     
  • 2.52, angra (ok), 13:22, 13/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Для этого придется пройти по ссылке и прочитать оригинал на английском. Там есть третья секция, утерянная при пересказе. При помощи FILE создается файл с триггером, который будет выполнен с правами 'root' и уже в триггере делается манипуляция с логами.
     

  • 1.53, Аноним (-), 13:35, 13/09/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    >Уязвимость позволяет локально или удалённо атаковать сервер MySQL и повысить свои привилегии до пользователя root.

    А какого хрена mysql вообще работает под root? Тот же postgres делает setgid/setuid после запуска.

     
     
  • 2.58, angra (ok), 14:32, 13/09/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Еще один нечитатель. Мускул не работает под рутом.
     

  • 1.61, CHERTS (??), 16:28, 13/09/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Эксплуатация возможно только если у пользователя есть право FILE или SUPER на БД, при нормальном распределении прав на базы, таких прав не дается, то есть и уязвимость не страшна.
     
     
  • 2.63, Shichael Migorin (?), 16:40, 13/09/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    В альтлинуксе именно так и есть.
     
  • 2.65, Ilya Indigo (ok), 16:45, 13/09/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > при нормальном распределении прав на базы...

    GRANT ALL PRIVILEGES ON 'db'.* TO user@localhost IDENTIFIED BY 'password';
    А это нормальное распределение?


     
     
  • 3.78, angra (ok), 00:32, 14/09/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да. При этом ни FILE, ни SUPER получены не будут. А вот так делать нельзя:
    GRANT ALL PRIVILEGES TO user@localhost IDENTIFIED BY 'password';
     
  • 2.74, Аноним (-), 23:09, 13/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Эксплуатация возможно только если у пользователя есть право FILE или SUPER на

    Ничего подобного, вы просто не дочитали до конца:

    It is worth to note that attackers could use one of the other vulnerabilities discovered
    by the author of this advisory which has been assigned a CVEID of CVE-2016-6663 and is
    pending disclosure. The undisclosed vulnerability makes it easy for certain attackers to
    create /var/lib/mysql/my.cnf file with arbitrary contents [b]without the FILE privilege[/b]
    requirement.
    ...
    It could also be combined with CVE-2016-6663 vulnerability which will be released
    shortly and could allow certain attackers to escalate their privileges to root
    even without FILE privilege.


     

  • 1.71, CHERTS (??), 21:27, 13/09/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >>GRANT ALL PRIVILEGES

    Такие разрешения дает только идиот. Максимум, что нужно для любого LAMP хостинга - SELECT,INSERT,UPDATE,DELETE,CREATE,DROP,ALTER
    Иногда нужно LOCK TABLES, INDEX
    Очень редко EXECUTE

     
     
  • 2.79, angra (ok), 00:38, 14/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    А ты бы поинтересовался для начала, что именно выдаст ALL при применении на DB, а не на пользователя как такового. Вдруг окажется, что как раз твой набор, плюс еще несколько полезных в реальности привилегий, но без всяких из списка server administration.
     

  • 1.73, ALex_hha (ok), 22:17, 13/09/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Для этого придется пройти по ссылке и прочитать оригинал на английском. Там есть третья секция, утерянная при пересказе.

    я собственно читал оригинал автора, который и нашел эту уязвимость - http://legalhackers.com/advisories/MySQL-Exploit-Remote-Root-Code-Execution-P

    > При помощи FILE создается файл с триггером, который будет выполнен с правами 'root' и уже в триггере делается манипуляция с логами.

    вы сами пробовали? У меня в centos 6 писало что нет прав, ну и опять таки, чтобы работал file нужна соответствующая привелегия, которая не является "стандартной". И получается, что просто аутентифицированного доступа к БД будет недостаточно.

     
     
  • 2.75, Аноним (-), 23:11, 13/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Посмотрите ещё раз упоминание CVE-2016-6663, который позволяет обойтись без прав FILE.

     
  • 2.80, angra (ok), 00:41, 14/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Согласен, но FILE все-таки выдается куда чаще, чем SUPER. Мне самому интересно увидеть обещанный вариант без FILE. Ждем-с.


     

  • 1.81, ALex_hha (ok), 01:09, 14/09/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Посмотрите ещё раз упоминание CVE-2016-6663, который позволяет обойтись без прав FILE.

    то ли я плохо читал, то ли не нашел, как именно можно создать /var/lib/mysql/my.cnf с нужными нам данными, используя CVE-2016-6663?

     
     
  • 2.83, Аноним (-), 02:09, 14/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > то ли я плохо читал, то ли не нашел, как именно можно
    > создать /var/lib/mysql/my.cnf с нужными нам данными, используя CVE-2016-6663?

    Почитай в багтрекере: https://bugzilla.novell.com/show_bug.cgi?id=CVE-2016-6662

     
  • 2.86, angra (ok), 04:18, 14/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Интересно, как ты читал CVE-2016-6663, если его детали пока еще не опубликованы. Вот когда будут, тогда и можно будет обсудить.
     

  • 1.88, ALex_hha (ok), 10:44, 14/09/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Интересно, как ты читал CVE-2016-6663, если его детали пока еще не опубликованы.

    имеется ввиду proof of concept, по ссылке, которую я привел выше.

    Кстати интересно, на ubuntu 14.04 вышел фикс только для CVE-2016-6662

    # apt-get changelog libmysqlclient18
    mysql-5.5 (5.5.52-0ubuntu0.14.04.1) trusty-security; urgency=medium

      * SECURITY UPDATE: Update to 5.5.52 to fix security issues - CVE-2016-6662

     
  • 1.91, Аноним (-), 16:29, 14/09/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Объясните тупому, у меня на сервере CentOS 6.6 и там только MySQL 5.1 - эта версия тоже уязвима? Или речь только про ветки 5.7, 5.6, 5.5?
     
     
  • 2.96, Andrew (??), 23:03, 15/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Согласно комментарию (https://bugzilla.redhat.com/show_bug.cgi?id=1375198#c13) уязвима, конечно же, но чуть менее, чем более новые версии:

    > The MySQL 5.1 packages in RHEL 6 do not implement support for library preloading, preventing the remote vector. Local privilege escalation as database user with FILE privileges to root is still possible.

     

  • 1.98, rvs2016 (ok), 23:03, 01/10/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А как можно атаковать удалённо, если skip-networking? При включённом skip-networking сетевые порты ж не прослушиваются и mysql не ожидает никаких подключений из сети.
     

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



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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