форумы  помощь  поиск  регистрация  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Критическая root-уязвимость в MySQL"	+/–
Сообщение от opennews (??) on 12-Сен-16, 17:54
Опубликованы (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 Новость: https://www.opennet.ru/opennews/art.shtml?num=45127
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Критическая root-уязвимость в MySQL"	+1 +/–
Сообщение от Аноним (??) on 12-Сен-16, 17:54
ах-ах-ах...ужас, ужас. Мысль о touch /var/lib/mysql/my.cnf && chattr +i /var/lib/mysql/my.cnf видимо слишком сложна для нагнетателей паники. (вроде бы это единственное место, где можно создать такой файл не от рута, и чтобы при этом он был прочитан хоть каким-то процессом, связанным с mysql) Второй вариант, понятно, выкинуть совершенно ненужный функционал из mysqld_safe, но лично мне не нравится сама идея что кто-то может что-то записать в конфиги, даже неиспользуемые. Правда, следующей идеей будет нагадить не в my.cnf, а в базу mysql.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	37. "Критическая root-уязвимость в MySQL"	+1 +/–
	Сообщение от Аноним (??) on 13-Сен-16, 10:24
	Я воспользовался четвертым вариантом и выкинул MySQL.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	76. "Критическая root-уязвимость в MySQL"	+/–
	Сообщение от gogo on 14-Сен-16, 00:15
	Как временный вариант, до выходы полноценного патча, это в принципе должно работать. Какая ирония судьбы, что такая дыра именно в mysql_SAFE
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	77. "Критическая root-уязвимость в MySQL"	+4 +/–
	Сообщение от gogo on 14-Сен-16, 00:19
	И, между прочем, классический случай наказания за нарушение unix-way - сделали прокладку для запуска демона и получили дырку.... ; )
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

	82. "Критическая root-уязвимость в MySQL"	+/–
	Сообщение от Аноним (??) on 14-Сен-16, 02:02
	> И, между прочем, классический случай наказания за нарушение unix-way - сделали прокладку > для запуска демона и получили дырку.... ; ) програмеры на шелле те еще безопасники, особенно забавно выглядит led который называется security officer аж.
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

2. "Критическая root-уязвимость в MySQL"	+/–
Сообщение от Ilya Indigo (ok) on 12-Сен-16, 18:06
> По сведению разработчиков SUSE проблема уже исправлена в MariaDB 10.0.27... Так какого чёрта в репах у них до сих пор 10.0.22? Вот теперь у меня уже подгорает. Хотя, порт 3306 закрыт, учётки только локальные, включая Гранта, а пользователь рут вообще отсутствует. Тут, скорее наоборот подфортило, что наконец-то её обновят в репах, уже не отвертятся. Хотя если бы они просто обновляли вовремя пакеты, как во всех нормальных ролингах, они бы вообще этой уязвимости подвержены не были бы.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	5. "Критическая root-уязвимость в MySQL"	+1 +/–
	Сообщение от Ян Злобин (ok) on 12-Сен-16, 18:48
	> Так какого чёрта в репах у них до сих пор 10.0.22? 10.0.26 в репах http://software.opensuse.org/package/mariadb
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	6. "Критическая root-уязвимость в MySQL"	+/–
	Сообщение от Ilya Indigo (ok) on 12-Сен-16, 18:53
	openSUSE Tumbleweed официальный выпуск     5.5.29 И битая ссылка на загрузку, так как информация уже года 2 там не обновляется.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	59. "Критическая root-уязвимость в MySQL"	+1 +/–
	Сообщение от Ян Злобин (ok) on 13-Сен-16, 14:44
	> openSUSE Tumbleweed > официальный выпуск >     5.5.29 > И битая ссылка на загрузку, так как информация уже года 2 там > не обновляется. Вот, что вижу я: http://yan.zlobin.name/files/software.opensuse.org.png
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	19. "Критическая root-уязвимость в MySQL"	–1 +/–
	Сообщение от rt (??) on 12-Сен-16, 22:29
	> Вот теперь у меня уже подгорает. :> /var/lib/mysql/my.cnf && chattr +i /var/lib/mysql/my.cnf Не благодари.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	23. "Критическая root-уязвимость в MySQL"	+/–
	Сообщение от KM on 13-Сен-16, 02:54
	До Кристины достучались?
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	31. "Критическая root-уязвимость в MySQL"	+/–
	Сообщение от Ilya Indigo (ok) on 13-Сен-16, 08:27
	> До Кристины достучались? Вот интересный вопрос. В принципе, да. Я подумал, что она русская, исходя из её русского имени и фамилии, написал ей прямо по-русски, за исключением фразы на английском, что если она не понимает, я переведу ей. Вчера мне она ответила и написала, что она Чежка. Вот так от, пришлось переформулировать, что бы я это смог выразить на английском, и ей снова написал на английском. И тут спустя несколько часов, я читаю эту новость. XD Думаю, Просто пророческое письмо. Если ответит сама, или даст контакты людей, которые уполномочены на это ответить, сообщу.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	33. "Критическая root-уязвимость в MySQL"	+/–
	Сообщение от KM on 13-Сен-16, 09:25
	Я полагаю, она и сама в курсе: https://bugzilla.novell.com/show_bug.cgi?id=CVE-2016-6662
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	42. "Критическая root-уязвимость в MySQL"	–1 +/–
	Сообщение от Ilya Indigo (ok) on 13-Сен-16, 10:46
	> Я полагаю, она и сама в курсе: https://bugzilla.novell.com/show_bug.cgi?id=CVE-2016-6662 Но если даже опеннет в курсе, то я и не сомневался что она в курсе тоже. :-) Но я бы хотел быть в курсе с причинами запоздалых обновлений.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	67. "Критическая root-уязвимость в MySQL"	+/–
	Сообщение от KM on 13-Сен-16, 17:36
	А по запоздалым обновлением она просветила вопрос? Ибо уже и самому интересно...
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	69. "Критическая root-уязвимость в MySQL"	–1 +/–
	Сообщение от Ilya Indigo (ok) on 13-Сен-16, 17:48
	> А по запоздалым обновлением она просветила вопрос? Ибо уже и самому интересно... Пока только написала, что запрос на перевод на ветку 10.1 уже был произведён, но был отклонён из-за "some troubles", что она только вышла из отпуска и займётся сейчас этим и вскоре mariadb перейдёт на ветку 10.1. Про что за "some troubles", где их можно посмотреть, про причину запоздалых обновлений (ну не 11 месяцев из 12 у неё же отпуск), и про не обновляющийся раздел Tumbleweed на software.opensuse.org, пока ещё не ответила.
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

	72. "Критическая root-уязвимость в MySQL"	+/–
	Сообщение от KM on 13-Сен-16, 21:37
	Важно уже то, что появился обратный отклик и что не приходится гадать и строить на этом разные теории...
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	92. "Критическая root-уязвимость в MySQL"	–1 +/–
	Сообщение от Ilya Indigo (ok) on 14-Сен-16, 17:09
	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.
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

	95. "Критическая root-уязвимость в MySQL"	–1 +/–
	Сообщение от Ilya Indigo (ok) on 15-Сен-16, 14:48
	> 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
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

	89. "Критическая root-уязвимость в MySQL"	+1 +/–
	Сообщение от Нет on 14-Сен-16, 14:53
	ПодфАртило. От слова "фарт", а не от слова "форт". Повезло, а не укрепило. В нагрузку, на всякий случай - "симпАтичный".
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	90. "Критическая root-уязвимость в MySQL"	+1 +/–
	Сообщение от Ilya Indigo (ok) on 14-Сен-16, 15:05
	Благодарю, запомню.
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

11. "Критическая root-уязвимость в MySQL"	+8 +/–
Сообщение от Аноним (??) on 12-Сен-16, 21:08
PostgreSQL решает проблему.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	22. "Критическая root-уязвимость в MySQL"	–1 +/–
	Сообщение от А (??) on 13-Сен-16, 00:53
	Привнося массу своих. https://eng.uber.com/mysql-migration/ Но Postgres - хорошая школа )
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	24. "Критическая root-уязвимость в MySQL"	–1 +/–
	Сообщение от Аноним (??) on 13-Сен-16, 04:23
	Хорошая школа - простой NoSQL. Который не умеет в произвольные файлы записывать, так что и ломать не получится.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	26. "Критическая root-уязвимость в MySQL"	+/–
	Сообщение от Аноним (??) on 13-Сен-16, 04:31
	А postgresql и не умеет, если специальными плагинами не обвеситься.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	48. "Критическая root-уязвимость в MySQL"	+/–
	Сообщение от 1 (??) on 13-Сен-16, 12:31
	COPY (SELECT 'asdf') TO '/tmp/asdf.txt'; https://www.postgresql.org/docs/current/static/sql-copy.html
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	55. "Критическая root-уязвимость в MySQL"	+/–
	Сообщение от Аноним (??) on 13-Сен-16, 13:40
	И правда. Тьфу на них!
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	28. "Критическая root-уязвимость в MySQL"	–3 +/–
	Сообщение от Лютый жабист_ on 13-Сен-16, 05:02
	Хорошая школа - простой NoSQL Для информации NoSQL расшифровывается как not only SQL. И по фичам та же Монга обруливает Мускуля огого как. ;)
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	32. "Критическая root-уязвимость в MySQL"	+6 +/–
	Сообщение от Аноним (??) on 13-Сен-16, 08:39
	Ровно до той поры, пока не нужна консистентность данных и сложные выборки. И жрёт оно на порядок больше.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	56. "Критическая root-уязвимость в MySQL"	+1 +/–
	Сообщение от Аноним (??) on 13-Сен-16, 13:50
	Единственная прям фича монги - это шардинг из коробки. Выбор же 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?
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	60. "Критическая root-уязвимость в MySQL"	+/–
	Сообщение от Аноним (??) on 13-Сен-16, 16:00
	> Для информации NoSQL расшифровывается как not only SQL. И по фичам та > же Монга обруливает Мускуля огого как. ;) так не надо пользоваться программами от жабистов-апачистов, не могут они в безопасность. сказано же - ПРОСТОЙ NoSQL. иди поломай базу key-value, я хочу посмотреть как это выглядеть будет. а если ты хотел хуяк-хуяк и в продакшн, тебе и будут сервера рутать и тебя не жалко.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	34. "Критическая root-уязвимость в MySQL"	+2 +/–
	Сообщение от Аноним (??) on 13-Сен-16, 09:49
	только лучший NoSQL - это тоже PostgreSQL :)
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	38. "Критическая root-уязвимость в MySQL"	+/–
	Сообщение от angra (ok) on 13-Сен-16, 10:25
	Скажи честно, NoSQL ты видел толко на картинке? Или ты говоришь о некой конкретной(возможно даже воображаемой) NoSQL, которая не умеет писать в произвольные файлы?
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	51. "Критическая root-уязвимость в MySQL"	+/–
	Сообщение от Аноним (??) on 13-Сен-16, 13:18
	Ага. DBF :)
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	66. "Критическая root-уязвимость в MySQL"	+/–
	Сообщение от Аноним (??) on 13-Сен-16, 17:24
	> Скажи честно, NoSQL ты видел толко на картинке? я еще и пользуюсь внаглую несколькими видами баз key-value и желаю удачи тебе и твоему дружку жабисту порутать это.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	87. "Критическая root-уязвимость в MySQL"	+1 +/–
	Сообщение от angra (ok) on 14-Сен-16, 06:36
	Но их названия ты конечно не скажешь. А то вдруг тебе покажут, как они могут писать в произвольный файл, обидно будет. Но даже, если они не такие, то существуют другие NoSQL, например Redis, которые это умеют и эта возможность использовалась для взлома. Мне вообще интересно, какая в твоей голове связь между SQL/NoSQL и возможностью писать в файлы.
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	44. "Критическая root-уязвимость в MySQL"	+/–
	Сообщение от ueueue on 13-Сен-16, 12:12
	Такой как redis? :) Понятно, что дело было не в бобине, и тем не менее.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	25. "Критическая root-уязвимость в MySQL"	+4 +/–
	Сообщение от Аноним (??) on 13-Сен-16, 04:29
	Если внимательнее прочитать, то понятно, что это всё не абсолютные преимущества или недостатки, а особенности реализации, имеющие свои плюсы и минусы в разных сценариях использования. Причем описаны исключительно общеизвестные, задокументированные вещи. Уберу стоило бы разобраться в том, как работает используемая СУБД, при проектировании системы, а не когда все начало становиться раком.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	41. "Критическая root-уязвимость в MySQL"	–1 +/–
	Сообщение от angra (ok) on 13-Сен-16, 10:30
	Неужто в документации сразу пишут об еще не обнаруженных багах? А может там пишут: "Репликацию мы сделали чисто для галочки, не используйте ее в продакшене, если вам дорог трафик" или "Забудьте про апгрейды в продакшене, если только вы не можете себе позволить пару часов даунтайма".
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	45. "Критическая root-уязвимость в MySQL"	+/–
	Сообщение от Аноним (??) on 13-Сен-16, 12:18
	> Неужто в документации сразу пишут об еще не обнаруженных багах Это вы так жестоко про MySQL? Килотонны багов на https://bugs.mysql.com/
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	49. "Критическая root-уязвимость в MySQL"	+/–
	Сообщение от angra (ok) on 13-Сен-16, 13:01
	Нет, не про мускул, не про постгрес и даже не про их сравнение по забагованности. Чтобы понять о чем речь, придется для начал прочитать очень много английских букв по приведенной выше ссылке. Справишься?
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	50. "Критическая root-уязвимость в MySQL"	+/–
	Сообщение от Аноним (??) on 13-Сен-16, 13:09
	ну у ребят из skype как то же получилось прочитать документацию :)
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	54. "Критическая root-уязвимость в MySQL"	+2 +/–
	Сообщение от Аноним (??) on 13-Сен-16, 13:36
	Репликацию сделали нормальную физическую. Физическая репликация потребляет трафик, да, тоже мне новость. Зато в постгресе есть WAL decoder, на основании которого можно спокойно реализовать логическую репликацию, причем не только в другой постгрес, а вообще куда угодно. Думаю, очень скоро реализуют более высокоуровневые средства. А вот в mysql из-за идиотского дизайна WAL и binary log это две разные сущности: binary log на уровне mysql (для репликции), а у InnoDB свой WAL, в который второй раз пишется ровно то же самое. И физическую репликацию в мыскле сделать нельзя вообще by design. А баг - баг этот был много лет назад и оперативно исправлен. Его упомянули просто потому что хотели что-то еще нехорошее написать, а идеи кончились. И это просто баг, который нашли и исправили. В мыскле все, что есть хорошее - это InnoDB, потому что его написали не они. InnoDB действительно хорош и в ряде сценариев использования эффективнее postgresql. А вот все, что написали сами разработчики мыскля - это один большой кусок запутанного и непродуманного лапшекода. Из-за него уже 10 лет не могут начать использовать для системных словарей innodb вместо myisam (и получить наконец версионность DDL). Очень хотят, но там настолько все прибито гвоздями и глобальными переменными к муисаму, что ничего сделать нельзя.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	57. "Критическая root-уязвимость в MySQL"	+/–
	Сообщение от angra (ok) on 13-Сен-16, 14:29
	> Репликацию сделали нормальную физическую. Какие критерии нормальности? Сразу начинаем с демагогии? Хороший старт. > Физическая репликация потребляет трафик, да,  тоже мне новость. Любая репликация потребляет трафик, это не новость. Вопрос в том, сколько именно она потребляет, насколько удачным является решение в условиях ненулевой стоимости трафика. Вариант постгреса оказался неудачным в определенных условиях, о чем человек подробно написал. Более того, в случае постгреса репликация тоже может потреблять сравнительно мало трафика. > Зато в постгресе есть WAL decoder, на основании которого можно спокойно реализовать > логическую репликацию, причем не только в другой постгрес, а вообще куда > угодно. Думаю, очень скоро реализуют более высокоуровневые средства. Вполне может быть, что в будущем постгрес избавится от всех проблем и станет лучшей БД. Но речь в статье была про суровое настоящее и даже прошлое, а не светлое будущее. > А вот в mysql из-за идиотского дизайна WAL и binary log это две разные сущности не как в постгресе != идиотский Опять эмоции и ярлыки > И физическую репликацию в мыскле сделать нельзя вообще by design. В смысле сделать как в постгресе? А зачем? > Его упомянули просто потому что хотели что-то еще нехорошее написать, а > идеи кончились. И это просто баг, который нашли и исправили. Он вообще-то упоминается в связи с проблематичностью апгрейда. > В мыскле все, что есть хорошее - это InnoDB Если так хорош InnoDB, то берите его в постгрес. Не можете? Дизайн не позволяет использовать произвольные движки? Так может мускул еще чем-то хорош? Например самой возможностью использовать разные движки хранения. Вот чем мне нравится оригинальная статья, так это объективностью. Человек детально описал условия использования и причины, по которым постгрес оказался неудачным решением _в этих условиях_. А вот фанаты не удосуживаются нормально вникнуть и сразу бросаются на защиту фетиша, аргументирую свою позицию по принципу "а у вас зато негров линчуют".
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	93. "Критическая root-уязвимость в MySQL"	+1 +/–
	Сообщение от Другой Аноним on 15-Сен-16, 08:37
	Мы не о настоящем говорим, а о прошлом, 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.
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	85. "Критическая root-уязвимость в MySQL"	+/–
	Сообщение от Аноним (??) on 14-Сен-16, 02:14
	> Репликацию сделали нормальную физическую. Физическая репликация потребляет трафик, да, > тоже мне новость. большие объемы траффика стоят много денег, поэтому если проект взлетает - потребление траффика начинает сильно бить по кошельку.
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	94. "Критическая root-уязвимость в MySQL"	+/–
	Сообщение от Другой Аноним on 15-Сен-16, 09:01
	>> Репликацию сделали нормальную физическую. Физическая репликация потребляет трафик, да, >> тоже мне новость. > большие объемы траффика стоят много денег, поэтому если проект взлетает - потребление > траффика начинает сильно бить по кошельку. физическая репликация надежнее. если у тебя пара серваков например с биллингом, в одной стойке - то разумный выбор физическая репликация. вполне логично что ее сделали сначала ее потом логическую.
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

12. "Критическая root-уязвимость в MySQL"	–1 +/–
Сообщение от Аноним (??) on 12-Сен-16, 21:14
И что, selinux в нормальных дистрибутивах не спасёт? Политиками разрешена запись в my.cnf?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	13. "Критическая root-уязвимость в MySQL"	+2 +/–
	Сообщение от Аноним (??) on 12-Сен-16, 21:37
	Скажу больше, selinux из коробки вообще не спасает. Только создает видимость безопасности с препятствиями.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	64. "Критическая root-уязвимость в MySQL"	–1 +/–
	Сообщение от Shichael Migorin on 13-Сен-16, 16:42
	В нормальных дистрибутивах (например в альтлинукс) нет selinux.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

18. "Критическая root-уязвимость в MySQL"	+/–
Сообщение от LinuxID (ok) on 12-Сен-16, 22:28
dev-db/mysql-5.6.31:0/18::gentoo dev-db/mariadb-10.0.26:0/18::gentoo Ждемс обновдений!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

21. "Критическая root-уязвимость в MySQL"	–1 +/–
Сообщение от stalker37 (ok) on 12-Сен-16, 23:05
В перконе уже пофиксили.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	29. "Критическая root-уязвимость в MySQL"	+/–
	Сообщение от Христофор on 13-Сен-16, 05:58
	Где в перконе пофиксили ? в репо 5.6.32.... а надо 5.6.33 Или я не прав?
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	47. "Критическая root-уязвимость в MySQL"	+/–
	Сообщение от stalker37 (ok) on 13-Сен-16, 12:22
	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
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

27. "Критическая root-уязвимость в MySQL"	+1 +/–
Сообщение от Аноним (??) on 13-Сен-16, 04:49
В марие пофиксили с третьей попытки. :) 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 Костыли, конечно, те еще.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

36. "Критическая root-уязвимость в MySQL"	+/–
Сообщение от Аноним (??) on 13-Сен-16, 10:12
Гмм...получается MariaDB 10.1 не уязвима?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	40. "Критическая root-уязвимость в MySQL"	+/–
	Сообщение от Аноним (??) on 13-Сен-16, 10:28
	> Гмм...получается MariaDB 10.1 не уязвима? Да похоже это не LTS
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

43. "Критическая root-уязвимость в MySQL"	+1 +/–
Сообщение от ALex_hha (ok) on 13-Сен-16, 11:20
Может кто-нибудь объяснить как подразумевается использовать эту уязвимость? Либо вот тут - "для эксплуатации требуется аутентифицированный доступ к БД" они что то не договаривают, ибо просто доступа к БД недостаточно. Так как, например, set global general_log_file требует SUPER privilege, а откуда они возьмутся у обычного пользователя?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	46. "Критическая root-уязвимость в MySQL"	+/–
	Сообщение от Аноним (??) on 13-Сен-16, 12:19
	> Может кто-нибудь объяснить как подразумевается использовать эту уязвимость? Либо вот тут > - "для эксплуатации требуется аутентифицированный доступ к БД" они что то > не договаривают, ибо просто доступа к БД недостаточно. Так как, например, > set global general_log_file требует SUPER privilege, а откуда они возьмутся у > обычного пользователя? Всякие движки ставят с правами SUPER privilege и оно это деплоит, это не под строгий проект.
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	84. "Критическая root-уязвимость в MySQL"	+/–
	Сообщение от Аноним (??) on 14-Сен-16, 02:11
	> Всякие движки ставят с правами SUPER privilege и оно это деплоит, это > не под строгий проект. получение рута на сервере - это не большой факап? может вы сразу тогда всем желающим рутовый доступ дадите, чтобы не надо было с мускулом извращаться?
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	52. "Критическая root-уязвимость в MySQL"	+/–
	Сообщение от angra (ok) on 13-Сен-16, 13:22
	Для этого придется пройти по ссылке и прочитать оригинал на английском. Там есть третья секция, утерянная при пересказе. При помощи FILE создается файл с триггером, который будет выполнен с правами 'root' и уже в триггере делается манипуляция с логами.
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

53. "Критическая root-уязвимость в MySQL"	–3 +/–
Сообщение от Аноним (??) on 13-Сен-16, 13:35
>Уязвимость позволяет локально или удалённо атаковать сервер MySQL и повысить свои привилегии до пользователя root. А какого хрена mysql вообще работает под root? Тот же postgres делает setgid/setuid после запуска.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	58. "Критическая root-уязвимость в MySQL"	+2 +/–
	Сообщение от angra (ok) on 13-Сен-16, 14:32
	Еще один нечитатель. Мускул не работает под рутом.
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

61. "Критическая root-уязвимость в MySQL"	+/–
Сообщение от CHERTS (??) on 13-Сен-16, 16:28
Эксплуатация возможно только если у пользователя есть право FILE или SUPER на БД, при нормальном распределении прав на базы, таких прав не дается, то есть и уязвимость не страшна.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	63. "Критическая root-уязвимость в MySQL"	–1 +/–
	Сообщение от Shichael Migorin on 13-Сен-16, 16:40
	В альтлинуксе именно так и есть.
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	65. "Критическая root-уязвимость в MySQL"	+1 +/–
	Сообщение от Ilya Indigo (ok) on 13-Сен-16, 16:45
	> при нормальном распределении прав на базы... GRANT ALL PRIVILEGES ON `db`.* TO user@localhost IDENTIFIED BY 'password'; А это нормальное распределение?
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	78. "Критическая root-уязвимость в MySQL"	+1 +/–
	Сообщение от angra (ok) on 14-Сен-16, 00:32
	Да. При этом ни FILE, ни SUPER получены не будут. А вот так делать нельзя: GRANT ALL PRIVILEGES TO user@localhost IDENTIFIED BY 'password';
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	74. "Критическая root-уязвимость в MySQL"	+/–
	Сообщение от Аноним (??) on 13-Сен-16, 23:09
	> Эксплуатация возможно только если у пользователя есть право 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.
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

71. "Критическая root-уязвимость в MySQL"	+/–
Сообщение от CHERTS (??) on 13-Сен-16, 21:27
>>GRANT ALL PRIVILEGES Такие разрешения дает только идиот. Максимум, что нужно для любого LAMP хостинга - SELECT,INSERT,UPDATE,DELETE,CREATE,DROP,ALTER Иногда нужно LOCK TABLES, INDEX Очень редко EXECUTE
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	79. "Критическая root-уязвимость в MySQL"	+/–
	Сообщение от angra (ok) on 14-Сен-16, 00:38
	А ты бы поинтересовался для начала, что именно выдаст ALL при применении на DB, а не на пользователя как такового. Вдруг окажется, что как раз твой набор, плюс еще несколько полезных в реальности привилегий, но без всяких из списка server administration.
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

73. "Критическая root-уязвимость в MySQL"	+/–
Сообщение от ALex_hha (ok) on 13-Сен-16, 22:17
> Для этого придется пройти по ссылке и прочитать оригинал на английском. Там есть третья секция, утерянная при пересказе. я собственно читал оригинал автора, который и нашел эту уязвимость - http://legalhackers.com/advisories/MySQL-Exploit-Remote-Root... > При помощи FILE создается файл с триггером, который будет выполнен с правами 'root' и уже в триггере делается манипуляция с логами. вы сами пробовали? У меня в centos 6 писало что нет прав, ну и опять таки, чтобы работал file нужна соответствующая привелегия, которая не является "стандартной". И получается, что просто аутентифицированного доступа к БД будет недостаточно.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	75. "Критическая root-уязвимость в MySQL"	+/–
	Сообщение от Аноним (??) on 13-Сен-16, 23:11
	Посмотрите ещё раз упоминание CVE-2016-6663, который позволяет обойтись без прав FILE.
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	80. "Критическая root-уязвимость в MySQL"	+/–
	Сообщение от angra (ok) on 14-Сен-16, 00:41
	Согласен, но FILE все-таки выдается куда чаще, чем SUPER. Мне самому интересно увидеть обещанный вариант без FILE. Ждем-с.
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

81. "Критическая root-уязвимость в MySQL"	+/–
Сообщение от ALex_hha (ok) on 14-Сен-16, 01:09
> Посмотрите ещё раз упоминание CVE-2016-6663, который позволяет обойтись без прав FILE. то ли я плохо читал, то ли не нашел, как именно можно создать /var/lib/mysql/my.cnf с нужными нам данными, используя CVE-2016-6663?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	83. "Критическая root-уязвимость в MySQL"	+/–
	Сообщение от Аноним (??) on 14-Сен-16, 02:09
	> то ли я плохо читал, то ли не нашел, как именно можно > создать /var/lib/mysql/my.cnf с нужными нам данными, используя CVE-2016-6663? Почитай в багтрекере: https://bugzilla.novell.com/show_bug.cgi?id=CVE-2016-6662
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	86. "Критическая root-уязвимость в MySQL"	+/–
	Сообщение от angra (ok) on 14-Сен-16, 04:18
	Интересно, как ты читал CVE-2016-6663, если его детали пока еще не опубликованы. Вот когда будут, тогда и можно будет обсудить.
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

88. "Критическая root-уязвимость в MySQL"	+/–
Сообщение от ALex_hha (ok) on 14-Сен-16, 10:44
> Интересно, как ты читал 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
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

91. "Критическая root-уязвимость в MySQL"	+/–
Сообщение от Аноним (??) on 14-Сен-16, 16:29
Объясните тупому, у меня на сервере CentOS 6.6 и там только MySQL 5.1 - эта версия тоже уязвима? Или речь только про ветки 5.7, 5.6, 5.5?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	96. "Критическая root-уязвимость в MySQL"	+/–
	Сообщение от Andrew (??) on 15-Сен-16, 23:03
	Согласно комментарию (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.
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

98. "Критическая root-уязвимость в MySQL"	+/–
Сообщение от rvs2016 (ok) on 01-Окт-16, 23:03
А как можно атаковать удалённо, если skip-networking? При включённом skip-networking сетевые порты ж не прослушиваются и mysql не ожидает никаких подключений из сети.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема