Опубликованы (http://legalhackers.com/advisories/MySQL-Exploit-Remote-Root...) сведения о критической уязвимости (CVE-2016-6662 (https://security-tracker.debian.org/tracker/CVE-2016-6662)) в MySQL и производных продуктах, таких как MariaDB и Percona Server. Уязвимость позволяет локально или удалённо атаковать сервер MySQL и повысить свои привилегии до пользователя root.Смягчает опасность то, что для эксплуатации требуется аутентифицированный доступ к БД или проведение дополнительной атаки на web-приложения, в результате которой необходимо получить возможность подстановки SQL-кода. Усугубляет проблему то, что опубликован начальный прототип эксплоита (полный эксплоит планируется опубликовать позднее, дав время на выпуск обновления), в то время как сама уязвимость ещё не исправлена (0-day) и проявляется в актуальных выпусках поддерживаемых веток MySQL - 5.7.15, 5.6.33 и 5.5.52. По сведению (https://bugzilla.novell.com/show_bug.cgi?id=CVE-2016-6662) разработчиков SUSE проблема уже исправлена в MySQL 5.5.52 и MariaDB 10.0.27. Обновления пакетов в дистрибутивах пока не выпущены (Ubuntu (https://people.canonical.com/~ubuntu-security/cve/2016/CVE-2...), Debian (https://security-tracker.debian.org/tracker/CVE-2016-6662), RHEL (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2016-6662), FreeBSD (http://www.vuxml.org/freebsd/), CentOS (https://lists.centos.org/pipermail/centos-announce/2016-Augu...), Fedora (https://bodhi.fedoraproject.org/updates/?releases=F23&type=s...), SUSE (https://bugzilla.novell.com/show_bug.cgi?id=CVE-2016-6662)).
Непосредственно выявленная уязвимость позволяет любому пользователю СУБД получить доступ к функциям работы с логами, которые должны быть доступны только пользователю admin. Через манипуляции с функциями записи в лог атакующий может изменить или создать файл конфигурации my.cnf. Если для файла my.cnf запрещена запись от пользователя mysql, то атакующий может создать новый файл в директории с данными ("_default_"), которая по умолчанию допускает запись пользователем mysql. Возможность выполнения кода с правами root достигается через загрузку подставной библиотеки при помощи LD_PRELOAD при очередном перезапуске mysql (процесс mysql работает от непривилерованного пользователя, но при запуске используются права root).
URL: http://openwall.com/lists/oss-security/2016/09/12/3
Новость: http://www.opennet.me/opennews/art.shtml?num=45127
ах-ах-ах...ужас, ужас.Мысль о touch /var/lib/mysql/my.cnf && chattr +i /var/lib/mysql/my.cnf
видимо слишком сложна для нагнетателей паники.
(вроде бы это единственное место, где можно создать такой файл не от рута, и чтобы при этом он был прочитан хоть каким-то процессом, связанным с mysql)Второй вариант, понятно, выкинуть совершенно ненужный функционал из mysqld_safe, но лично мне не нравится сама идея что кто-то может что-то записать в конфиги, даже неиспользуемые.
Правда, следующей идеей будет нагадить не в my.cnf, а в базу mysql.
Я воспользовался четвертым вариантом и выкинул MySQL.
Как временный вариант, до выходы полноценного патча, это в принципе должно работать.Какая ирония судьбы, что такая дыра именно в mysql_SAFE
И, между прочем, классический случай наказания за нарушение unix-way - сделали прокладку для запуска демона и получили дырку.... ; )
> И, между прочем, классический случай наказания за нарушение unix-way - сделали прокладку
> для запуска демона и получили дырку.... ; )програмеры на шелле те еще безопасники, особенно забавно выглядит led который называется security officer аж.
> По сведению разработчиков SUSE проблема уже исправлена в MariaDB 10.0.27...Так какого чёрта в репах у них до сих пор 10.0.22?
Вот теперь у меня уже подгорает.
Хотя, порт 3306 закрыт, учётки только локальные, включая Гранта, а пользователь рут вообще отсутствует.
Тут, скорее наоборот подфортило, что наконец-то её обновят в репах, уже не отвертятся.
Хотя если бы они просто обновляли вовремя пакеты, как во всех нормальных ролингах, они бы вообще этой уязвимости подвержены не были бы.
> Так какого чёрта в репах у них до сих пор 10.0.22?10.0.26 в репах
http://software.opensuse.org/package/mariadb
openSUSE Tumbleweed
официальный выпуск5.5.29
И битая ссылка на загрузку, так как информация уже года 2 там не обновляется.
> openSUSE Tumbleweed
> официальный выпуск
> 5.5.29
> И битая ссылка на загрузку, так как информация уже года 2 там
> не обновляется.Вот, что вижу я:
http://yan.zlobin.name/files/software.opensuse.org.png
> Вот теперь у меня уже подгорает.:> /var/lib/mysql/my.cnf && chattr +i /var/lib/mysql/my.cnf
Не благодари.
До Кристины достучались?
> До Кристины достучались?Вот интересный вопрос. В принципе, да. Я подумал, что она русская, исходя из её русского имени и фамилии, написал ей прямо по-русски, за исключением фразы на английском, что если она не понимает, я переведу ей.
Вчера мне она ответила и написала, что она Чежка. Вот так от, пришлось переформулировать, что бы я это смог выразить на английском, и ей снова написал на английском.
И тут спустя несколько часов, я читаю эту новость. XD
Думаю, Просто пророческое письмо. Если ответит сама, или даст контакты людей, которые уполномочены на это ответить, сообщу.
Я полагаю, она и сама в курсе: https://bugzilla.novell.com/show_bug.cgi?id=CVE-2016-6662
> Я полагаю, она и сама в курсе: https://bugzilla.novell.com/show_bug.cgi?id=CVE-2016-6662Но если даже опеннет в курсе, то я и не сомневался что она в курсе тоже. :-)
Но я бы хотел быть в курсе с причинами запоздалых обновлений.
А по запоздалым обновлением она просветила вопрос? Ибо уже и самому интересно...
> А по запоздалым обновлением она просветила вопрос? Ибо уже и самому интересно...Пока только написала, что запрос на перевод на ветку 10.1 уже был произведён, но был отклонён из-за "some troubles", что она только вышла из отпуска и займётся сейчас этим и вскоре mariadb перейдёт на ветку 10.1.
Про что за "some troubles", где их можно посмотреть, про причину запоздалых обновлений (ну не 11 месяцев из 12 у неё же отпуск), и про не обновляющийся раздел Tumbleweed на software.opensuse.org, пока ещё не ответила.
Важно уже то, что появился обратный отклик и что не приходится гадать и строить на этом разные теории...
Thank you for your email. I'm out of the office and will be back at 2016-09-19. If you need immediate assistance during my absence, please contact Tomas Chvatal (tchvatal@suse.cz). Otherwise, I will respond to your emails as soon as possible upon my return.
Мда, мне бы такую работу, что бы я был постоянно в отпусках, работал бы только когда приспичит, и мне при этом бы исправно платили.
Похоже теперь я понимаю, почему MariaDB так редко обновляется в openSUSE.
> You write:> because of some troubles And what kind of problems
> arise when updating the code in the current branch, and when moving
> to another branch? They can be anywhere to see? The only known me a
> package that depends on it mariadb akonadi-server through
> libQt5Sql5-mysql. It would seem that you just need to update the
> source code and compile the package, and track that would
> libQt5Sql5-mysql and perhaps other providers mysql successfully
> met, especially if the update prededah one branch. Or is it much
> more difficult, and I do not understand something?You can see the declined request here [0]. I have to say that I was
quite busy for the last few weeks but now it should be better and I
hope I will finish the migration to 10.1. branch soon.> I and some members of the Russian-speaking resource, about open
> software ( www.opennet.ru), are very interested why openSUSE
> Tumbleweed some packages updated fairly quickly (eg php), and some,
> like mariadb and the openssh, can not be updated more than a year
> ?It always depends on the maintainer and mainly on the community around
the package. There are some packages with awesome community that
handles all version and other updates and there are some "not so
popular" packages where all the work is just on the packager.> More interested in, if you are familiar with this problem, why the
> site is not working properly software.opensuse.org search packages
> to Tumbleweed? For example
> https://software.opensuse.org/package/mariadb tab for Tumbleweed
> shows a very old package 5.5.29, with broken links?
>Sorry, but I'm not in charge of this site. However, I guess you can
file a new issue in GitHub [1] or write an email to admin [2].> I wish you a productive, joyful and pleasant day! :-)
You too :)
Best Ragards,
Kristyna Streitova[0] https://build.opensuse.org/request/show/402002
[1] https://github.com/openSUSE/software-o-o/issues
[2] admin@opensuse.org
ПодфАртило. От слова "фарт", а не от слова "форт". Повезло, а не укрепило.
В нагрузку, на всякий случай - "симпАтичный".
Благодарю, запомню.
PostgreSQL решает проблему.
Привнося массу своих.https://eng.uber.com/mysql-migration/
Но Postgres - хорошая школа )
Хорошая школа - простой NoSQL. Который не умеет в произвольные файлы записывать, так что и ломать не получится.
А postgresql и не умеет, если специальными плагинами не обвеситься.
COPY (SELECT 'asdf') TO '/tmp/asdf.txt';
https://www.postgresql.org/docs/current/static/sql-copy.html
И правда. Тьфу на них!
Хорошая школа - простой NoSQLДля информации NoSQL расшифровывается как not only SQL. И по фичам та же Монга обруливает Мускуля огого как. ;)
Ровно до той поры, пока не нужна консистентность данных и сложные выборки. И жрёт оно на порядок больше.
Единственная прям фича монги - это шардинг из коробки.Выбор же 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?
> Для информации NoSQL расшифровывается как not only SQL. И по фичам та
> же Монга обруливает Мускуля огого как. ;)так не надо пользоваться программами от жабистов-апачистов, не могут они в безопасность. сказано же - ПРОСТОЙ NoSQL. иди поломай базу key-value, я хочу посмотреть как это выглядеть будет. а если ты хотел хуяк-хуяк и в продакшн, тебе и будут сервера рутать и тебя не жалко.
только лучший NoSQL - это тоже PostgreSQL :)
Скажи честно, NoSQL ты видел толко на картинке? Или ты говоришь о некой конкретной(возможно даже воображаемой) NoSQL, которая не умеет писать в произвольные файлы?
Ага. DBF :)
> Скажи честно, NoSQL ты видел толко на картинке?я еще и пользуюсь внаглую несколькими видами баз key-value и желаю удачи тебе и твоему дружку жабисту порутать это.
Но их названия ты конечно не скажешь. А то вдруг тебе покажут, как они могут писать в произвольный файл, обидно будет. Но даже, если они не такие, то существуют другие NoSQL, например Redis, которые это умеют и эта возможность использовалась для взлома. Мне вообще интересно, какая в твоей голове связь между SQL/NoSQL и возможностью писать в файлы.
Такой как redis? :) Понятно, что дело было не в бобине, и тем не менее.
Если внимательнее прочитать, то понятно, что это всё не абсолютные преимущества или недостатки, а особенности реализации, имеющие свои плюсы и минусы в разных сценариях использования. Причем описаны исключительно общеизвестные, задокументированные вещи. Уберу стоило бы разобраться в том, как работает используемая СУБД, при проектировании системы, а не когда все начало становиться раком.
Неужто в документации сразу пишут об еще не обнаруженных багах? А может там пишут: "Репликацию мы сделали чисто для галочки, не используйте ее в продакшене, если вам дорог трафик" или "Забудьте про апгрейды в продакшене, если только вы не можете себе позволить пару часов даунтайма".
> Неужто в документации сразу пишут об еще не обнаруженных багахЭто вы так жестоко про MySQL?
Килотонны багов на https://bugs.mysql.com/
Нет, не про мускул, не про постгрес и даже не про их сравнение по забагованности. Чтобы понять о чем речь, придется для начал прочитать очень много английских букв по приведенной выше ссылке. Справишься?
ну у ребят из skype как то же получилось прочитать документацию :)
Репликацию сделали нормальную физическую. Физическая репликация потребляет трафик, да, тоже мне новость.Зато в постгресе есть WAL decoder, на основании которого можно спокойно реализовать логическую репликацию, причем не только в другой постгрес, а вообще куда угодно. Думаю, очень скоро реализуют более высокоуровневые средства.
А вот в mysql из-за идиотского дизайна WAL и binary log это две разные сущности: binary log на уровне mysql (для репликции), а у InnoDB свой WAL, в который второй раз пишется ровно то же самое. И физическую репликацию в мыскле сделать нельзя вообще by design.
А баг - баг этот был много лет назад и оперативно исправлен. Его упомянули просто потому что хотели что-то еще нехорошее написать, а идеи кончились. И это просто баг, который нашли и исправили.
В мыскле все, что есть хорошее - это InnoDB, потому что его написали не они. InnoDB действительно хорош и в ряде сценариев использования эффективнее postgresql. А вот все, что написали сами разработчики мыскля - это один большой кусок запутанного и непродуманного лапшекода. Из-за него уже 10 лет не могут начать использовать для системных словарей innodb вместо myisam (и получить наконец версионность DDL). Очень хотят, но там настолько все прибито гвоздями и глобальными переменными к муисаму, что ничего сделать нельзя.
> Репликацию сделали нормальную физическую.Какие критерии нормальности? Сразу начинаем с демагогии? Хороший старт.
> Физическая репликация потребляет трафик, да, тоже мне новость.
Любая репликация потребляет трафик, это не новость. Вопрос в том, сколько именно она потребляет, насколько удачным является решение в условиях ненулевой стоимости трафика. Вариант постгреса оказался неудачным в определенных условиях, о чем человек подробно написал. Более того, в случае постгреса репликация тоже может потреблять сравнительно мало трафика.
> Зато в постгресе есть WAL decoder, на основании которого можно спокойно реализовать
> логическую репликацию, причем не только в другой постгрес, а вообще куда
> угодно. Думаю, очень скоро реализуют более высокоуровневые средства.Вполне может быть, что в будущем постгрес избавится от всех проблем и станет лучшей БД. Но речь в статье была про суровое настоящее и даже прошлое, а не светлое будущее.
> А вот в mysql из-за идиотского дизайна WAL и binary log это две разные сущности
не как в постгресе != идиотский
Опять эмоции и ярлыки> И физическую репликацию в мыскле сделать нельзя вообще by design.
В смысле сделать как в постгресе? А зачем?
> Его упомянули просто потому что хотели что-то еще нехорошее написать, а
> идеи кончились. И это просто баг, который нашли и исправили.Он вообще-то упоминается в связи с проблематичностью апгрейда.
> В мыскле все, что есть хорошее - это InnoDB
Если так хорош InnoDB, то берите его в постгрес. Не можете? Дизайн не позволяет использовать произвольные движки? Так может мускул еще чем-то хорош? Например самой возможностью использовать разные движки хранения.
Вот чем мне нравится оригинальная статья, так это объективностью. Человек детально описал условия использования и причины, по которым постгрес оказался неудачным решением _в этих условиях_. А вот фанаты не удосуживаются нормально вникнуть и сразу бросаются на защиту фетиша, аргументирую свою позицию по принципу "а у вас зато негров линчуют".
Мы не о настоящем говорим, а о прошлом, WAL decoder уже есть - pglogical, даже в статье uber-а про него написано:If you are running Postgres 9.4 or later, you could use something like pglogical, which implements a logical replication layer for Postgres. Using pglogical, you can replicate data among different Postgres releases, meaning that it’s possible to do an upgrade such as 9.4 to 9.5 without incurring significant downtime. This capability is still problematic because it’s not integrated into the Postgres mainline tree, and pglogical is still not an option for people running on older Postgres releases.
что касается "problematic" - это конечно очень "объективный" и не "демагогический" аргумент, только не понятно много бы осталось от исходной статьи без него, к тому же: pglogical is fully open source, released under the PostgreSQL licence with copyright novated to the PostgreSQL Development Group. It has also been submitted to PostgreSQL core as a candidate for inclusion in PostgreSQL 10.0. а так же InnoDB тоже не всегда в MySQL был если что, и не всегда хорошо работал.
> Если так хорош InnoDB, то берите его в постгрес. Не можете? Дизайн не позволяет использовать произвольные движки? Так может мускул еще чем-то хорош? Например самой возможностью использовать разные движки хранения.
что толку от этих движков если такие вещи как jsonb и fdw цветут и пахнут именно в postgresql.
> Репликацию сделали нормальную физическую. Физическая репликация потребляет трафик, да,
> тоже мне новость.большие объемы траффика стоят много денег, поэтому если проект взлетает - потребление траффика начинает сильно бить по кошельку.
>> Репликацию сделали нормальную физическую. Физическая репликация потребляет трафик, да,
>> тоже мне новость.
> большие объемы траффика стоят много денег, поэтому если проект взлетает - потребление
> траффика начинает сильно бить по кошельку.физическая репликация надежнее. если у тебя пара серваков например с биллингом, в одной стойке - то разумный выбор физическая репликация. вполне логично что ее сделали сначала ее потом логическую.
И что, selinux в нормальных дистрибутивах не спасёт? Политиками разрешена запись в my.cnf?
Скажу больше, selinux из коробки вообще не спасает.
Только создает видимость безопасности с препятствиями.
В нормальных дистрибутивах (например в альтлинукс) нет selinux.
dev-db/mysql-5.6.31:0/18::gentoo
dev-db/mariadb-10.0.26:0/18::gentoo
Ждемс обновдений!
В перконе уже пофиксили.
Где в перконе пофиксили ? в репо 5.6.32.... а надо 5.6.33
Или я не прав?
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) https://github.com/MariaDB/server/commit/470f259
2) \0, хехе https://github.com/MariaDB/server/commit/2a54a53
3) про венду вспомнили https://github.com/MariaDB/server/commit/0098d78Костыли, конечно, те еще.
Гмм...получается MariaDB 10.1 не уязвима?
> Гмм...получается MariaDB 10.1 не уязвима?Да похоже это не LTS
Может кто-нибудь объяснить как подразумевается использовать эту уязвимость? Либо вот тут - "для эксплуатации требуется аутентифицированный доступ к БД" они что то не договаривают, ибо просто доступа к БД недостаточно. Так как, например, set global general_log_file требует SUPER privilege, а откуда они возьмутся у обычного пользователя?
> Может кто-нибудь объяснить как подразумевается использовать эту уязвимость? Либо вот тут
> - "для эксплуатации требуется аутентифицированный доступ к БД" они что то
> не договаривают, ибо просто доступа к БД недостаточно. Так как, например,
> set global general_log_file требует SUPER privilege, а откуда они возьмутся у
> обычного пользователя?Всякие движки ставят с правами SUPER privilege и оно это деплоит, это не под строгий проект.
> Всякие движки ставят с правами SUPER privilege и оно это деплоит, это
> не под строгий проект.получение рута на сервере - это не большой факап? может вы сразу тогда всем желающим рутовый доступ дадите, чтобы не надо было с мускулом извращаться?
Для этого придется пройти по ссылке и прочитать оригинал на английском. Там есть третья секция, утерянная при пересказе. При помощи FILE создается файл с триггером, который будет выполнен с правами 'root' и уже в триггере делается манипуляция с логами.
>Уязвимость позволяет локально или удалённо атаковать сервер MySQL и повысить свои привилегии до пользователя root.А какого хрена mysql вообще работает под root? Тот же postgres делает setgid/setuid после запуска.
Еще один нечитатель. Мускул не работает под рутом.
Эксплуатация возможно только если у пользователя есть право FILE или SUPER на БД, при нормальном распределении прав на базы, таких прав не дается, то есть и уязвимость не страшна.
В альтлинуксе именно так и есть.
> при нормальном распределении прав на базы...GRANT ALL PRIVILEGES ON `db`.* TO user@localhost IDENTIFIED BY 'password';
А это нормальное распределение?
Да. При этом ни FILE, ни SUPER получены не будут. А вот так делать нельзя:
GRANT ALL PRIVILEGES TO user@localhost IDENTIFIED BY 'password';
> Эксплуатация возможно только если у пользователя есть право 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 without the FILE privilege
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.
>>GRANT ALL PRIVILEGESТакие разрешения дает только идиот. Максимум, что нужно для любого LAMP хостинга - SELECT,INSERT,UPDATE,DELETE,CREATE,DROP,ALTER
Иногда нужно LOCK TABLES, INDEX
Очень редко EXECUTE
А ты бы поинтересовался для начала, что именно выдаст ALL при применении на DB, а не на пользователя как такового. Вдруг окажется, что как раз твой набор, плюс еще несколько полезных в реальности привилегий, но без всяких из списка server administration.
> Для этого придется пройти по ссылке и прочитать оригинал на английском. Там есть третья секция, утерянная при пересказе.я собственно читал оригинал автора, который и нашел эту уязвимость - http://legalhackers.com/advisories/MySQL-Exploit-Remote-Root...
> При помощи FILE создается файл с триггером, который будет выполнен с правами 'root' и уже в триггере делается манипуляция с логами.
вы сами пробовали? У меня в centos 6 писало что нет прав, ну и опять таки, чтобы работал file нужна соответствующая привелегия, которая не является "стандартной". И получается, что просто аутентифицированного доступа к БД будет недостаточно.
Посмотрите ещё раз упоминание CVE-2016-6663, который позволяет обойтись без прав FILE.
Согласен, но FILE все-таки выдается куда чаще, чем SUPER. Мне самому интересно увидеть обещанный вариант без FILE. Ждем-с.
> Посмотрите ещё раз упоминание CVE-2016-6663, который позволяет обойтись без прав FILE.то ли я плохо читал, то ли не нашел, как именно можно создать /var/lib/mysql/my.cnf с нужными нам данными, используя CVE-2016-6663?
> то ли я плохо читал, то ли не нашел, как именно можно
> создать /var/lib/mysql/my.cnf с нужными нам данными, используя CVE-2016-6663?Почитай в багтрекере: https://bugzilla.novell.com/show_bug.cgi?id=CVE-2016-6662
Интересно, как ты читал CVE-2016-6663, если его детали пока еще не опубликованы. Вот когда будут, тогда и можно будет обсудить.
> Интересно, как ты читал 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
Объясните тупому, у меня на сервере CentOS 6.6 и там только MySQL 5.1 - эта версия тоже уязвима? Или речь только про ветки 5.7, 5.6, 5.5?
Согласно комментарию (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.
А как можно атаковать удалённо, если skip-networking? При включённом skip-networking сетевые порты ж не прослушиваются и mysql не ожидает никаких подключений из сети.
