Разработчики MariaDB оперативно отреагировали на опубликованные (http://www.opennet.me/opennews/art.shtml?num=35486) в выходные эксплоиты, использующие zero-day уязвимости в кодовой базе MySQL. В экстренном порядке выпущены (http://openquery.com/blog/mariadb-security-updates) обновления MariaDB 5.5.28a, 5.3.11, 5.2.13 и 5.1.66, в которых устранена проблема CVE-2012-5579, позволяющая аутентифицированному пользователю запустить код с правами процесса mysqld.

Из остальных проблем:

-  CVE-2012-5611 дублирует уже исправленную  уязвимость  CVE-2012-5579;
-  CVE-2012-5612 и CVE-2012-5614 - позволяют вызвать крах процесса. Проблемы будут (https://mariadb.atlassian.net/browse/MDEV-3908) исправлены (https://mariadb.atlassian.net/browse/MDEV-3910) в ближайшее время;
-  CVE-2012-5613 - не признана уязвимостью, так как для эксплуатации требуется наличие привилегий FILE, которые могут появиться у обычного пользователя только из-за ошибки администратора. Разработчик эксплоита не согласился (http://seclists.org/oss-sec/2012/q4/389) с такой точкой зрения, указав, что получения прав "ADMIN" имея только права "FILE" не является штатным поведением;
-  CVE-2012-5615 - метод обнаружения наличия пользователя, разработчики MariaDB ищут (https://mariadb.atlassian.net/browse/MDEV-3909) способ блокировать проблему;

Дополнительно отмечается, что компания Oracle пока никак не отреагировала на наличие данных проблем в MySQL. О времени выхода обновления для MySQL пока ничего не известно.

URL: http://openquery.com/blog/mariadb-security-updates
Новость: http://www.opennet.me/opennews/art.shtml?num=35490

• Обновление MariaDB с устранением zero-day уязвимости, затраг...,GentooBoy, 20:07 , 03-Дек-12
  • Обновление MariaDB с устранением zero-day уязвимости, затраг...,Аноним, 20:50 , 03-Дек-12
  • Обновление MariaDB с устранением zero-day уязвимости, затраг...,Andreys, 08:55 , 04-Дек-12
• Обновление MariaDB с устранением zero-day уязвимости, затраг...,Crazy Alex, 20:20 , 03-Дек-12
  • Обновление MariaDB с устранением zero-day уязвимости, затраг...,Z, 20:34 , 03-Дек-12
    • Обновление MariaDB с устранением zero-day уязвимости, затраг...,Crazy Alex, 15:15 , 04-Дек-12
  • Обновление MariaDB с устранением zero-day уязвимости, затраг...,Etch, 20:39 , 03-Дек-12
    • Обновление MariaDB с устранением zero-day уязвимости, затраг...,Anonym, 20:42 , 03-Дек-12
      • Обновление MariaDB с устранением zero-day уязвимости, затраг...,Аноним, 20:52 , 03-Дек-12
        • Обновление MariaDB с устранением zero-day уязвимости, затраг...,all_glory_to_the_hypnotoad, 21:10 , 03-Дек-12
          • Обновление MariaDB с устранением zero-day уязвимости, затраг...,Etch, 21:26 , 03-Дек-12
            • Обновление MariaDB с устранением zero-day уязвимости, затраг...,all_glory_to_the_hypnotoad, 22:30 , 03-Дек-12
              • Обновление MariaDB с устранением zero-day уязвимости, затраг...,Etch, 00:35 , 04-Дек-12
                • Обновление MariaDB с устранением zero-day уязвимости, затраг...,all_glory_to_the_hypnotoad, 00:50 , 04-Дек-12
                  • Обновление MariaDB с устранением zero-day уязвимости, затраг...,Etch, 01:35 , 04-Дек-12
          • Обновление MariaDB с устранением zero-day уязвимости, затраг...,Аноним, 00:52 , 04-Дек-12
        • Обновление MariaDB с устранением zero-day уязвимости, затраг...,Anonym, 23:16 , 03-Дек-12
          • Обновление MariaDB с устранением zero-day уязвимости, затраг...,all_glory_to_the_hypnotoad, 23:56 , 03-Дек-12
      • Обновление MariaDB с устранением zero-day уязвимости, затраг...,Adui, 21:10 , 03-Дек-12
        • Обновление MariaDB с устранением zero-day уязвимости, затраг...,Genix, 22:18 , 03-Дек-12
          • Обновление MariaDB с устранением zero-day уязвимости, затраг...,angra, 22:41 , 03-Дек-12
          • Обновление MariaDB с устранением zero-day уязвимости, затраг...,Аноним, 00:53 , 04-Дек-12
        • Обновление MariaDB с устранением zero-day уязвимости, затраг...,Anonym, 23:18 , 03-Дек-12
          • Обновление MariaDB с устранением zero-day уязвимости, затраг...,Adui, 01:11 , 04-Дек-12
      • Обновление MariaDB с устранением zero-day уязвимости, затраг...,Crazy Alex, 15:16 , 04-Дек-12
        • Обновление MariaDB с устранением zero-day уязвимости, затраг...,Adui, 18:34 , 04-Дек-12
          • Обновление MariaDB с устранением zero-day уязвимости,...,arisu, 19:23 , 04-Дек-12
    • Обновление MariaDB с устранением zero-day уязвимости, затраг...,XoRe, 22:59 , 03-Дек-12
    • Обновление MariaDB с устранением zero-day уязвимости, затраг...,Anonym, 23:37 , 03-Дек-12
    • Обновление MariaDB с устранением zero-day уязвимости, затраг...,Moomintroll, 08:50 , 04-Дек-12
    • Обновление MariaDB с устранением zero-day уязвимости, затраг...,Crazy Alex, 15:15 , 04-Дек-12
• Обновление MariaDB с устранением zero-day уязвимости, затраг...,Etch, 20:34 , 03-Дек-12
  • Обновление MariaDB с устранением zero-day уязвимости, затраг...,AlexAT, 20:39 , 03-Дек-12
    • Обновление MariaDB с устранением zero-day уязвимости, затраг...,Etch, 20:44 , 03-Дек-12
      • Обновление MariaDB с устранением zero-day уязвимости, затраг...,Xasd, 21:41 , 03-Дек-12
    • Обновление MariaDB с устранением zero-day уязвимости, затраг...,angra, 22:52 , 03-Дек-12
      • Обновление MariaDB с устранением zero-day уязвимости, затраг...,AlexAT, 22:55 , 03-Дек-12
        • Обновление MariaDB с устранением zero-day уязвимости, затраг...,angra, 23:46 , 03-Дек-12
          • Обновление MariaDB с устранением zero-day уязвимости, затраг...,AlexAT, 10:03 , 04-Дек-12
            • Обновление MariaDB с устранением zero-day уязвимости, затраг...,angra, 13:35 , 04-Дек-12
              • Обновление MariaDB с устранением zero-day уязвимости, затраг...,AlexAT, 15:14 , 04-Дек-12
• Обновление MariaDB с устранением zero-day уязвимости, затраг...,myhand, 20:43 , 03-Дек-12
  • Обновление MariaDB с устранением zero-day уязвимости, затраг...,Etch, 20:49 , 03-Дек-12
    • Обновление MariaDB с устранением zero-day уязвимости, затраг...,myhand, 20:58 , 03-Дек-12
      • Обновление MariaDB с устранением zero-day уязвимости, затраг...,Etch, 21:06 , 03-Дек-12
        • Обновление MariaDB с устранением zero-day уязвимости,...,arisu, 21:57 , 03-Дек-12
          • Обновление MariaDB с устранением zero-day уязвимости,...,Genix, 22:19 , 03-Дек-12
            • Обновление MariaDB с устранением zero-day уязвимости,...,arisu, 22:24 , 03-Дек-12
          • Обновление MariaDB с устранением zero-day уязвимости,...,Etch, 22:46 , 03-Дек-12
            • Обновление MariaDB с устранением zero-day уязвимости,...,AlexAT, 22:48 , 03-Дек-12
              • Обновление MariaDB с устранением zero-day уязвимости,...,angra, 23:02 , 03-Дек-12
                • Обновление MariaDB с устранением zero-day уязвимости,...,Аноним, 23:33 , 03-Дек-12
                • Обновление MariaDB с устранением zero-day уязвимости,...,AlexAT, 07:15 , 04-Дек-12
                  • Обновление MariaDB с устранением zero-day уязвимости,...,angra, 13:37 , 04-Дек-12
            • Обновление MariaDB с устранением zero-day уязвимости,...,arisu, 22:52 , 03-Дек-12
              • Обновление MariaDB с устранением zero-day уязвимости,...,Etch, 23:47 , 03-Дек-12
                • Обновление MariaDB с устранением zero-day уязвимости,...,arisu, 00:01 , 04-Дек-12
            • Обновление MariaDB с устранением zero-day уязвимости,...,all_glory_to_the_hypnotoad, 23:22 , 03-Дек-12
              • Обновление MariaDB с устранением zero-day уязвимости,...,Etch, 23:37 , 03-Дек-12
                • Обновление MariaDB с устранением zero-day уязвимости,...,all_glory_to_the_hypnotoad, 23:46 , 03-Дек-12
                  • Обновление MariaDB с устранением zero-day уязвимости,...,Etch, 00:18 , 04-Дек-12
                    • Обновление MariaDB с устранением zero-day уязвимости,...,arisu, 00:35 , 04-Дек-12
                      • Обновление MariaDB с устранением zero-day уязвимости,...,Etch, 01:21 , 04-Дек-12
                        • Обновление MariaDB с устранением zero-day уязвимости,...,arisu, 09:38 , 04-Дек-12
            • Обновление MariaDB с устранением zero-day уязвимости,...,myhand, 12:55 , 04-Дек-12
            • Обновление MariaDB с устранением zero-day уязвимости,...,Elhana, 18:17 , 17-Дек-12
              • Обновление MariaDB с устранением zero-day уязвимости,...,Etch, 06:32 , 18-Дек-12
        • Обновление MariaDB с устранением zero-day уязвимости, затраг...,myhand, 22:34 , 03-Дек-12
          • Обновление MariaDB с устранением zero-day уязвимости, затраг...,Etch, 23:25 , 03-Дек-12
            • Обновление MariaDB с устранением zero-day уязвимости, затраг...,ZloySergant, 00:23 , 04-Дек-12
              • Обновление MariaDB с устранением zero-day уязвимости, затраг...,Etch, 01:20 , 04-Дек-12
                • Обновление MariaDB с устранением zero-day уязвимости, затраг...,Kot, 04:50 , 04-Дек-12
                  • Обновление MariaDB с устранением zero-day уязвимости,...,arisu, 09:42 , 04-Дек-12
                • Обновление MariaDB с устранением zero-day уязвимости,...,arisu, 09:40 , 04-Дек-12
            • Обновление MariaDB с устранением zero-day уязвимости, затраг...,myhand, 13:04 , 04-Дек-12
• Обновление MariaDB с устранением zero-day уязвимости, затраг...,Sauron, 23:02 , 03-Дек-12
  • Обновление MariaDB с устранением zero-day уязвимости, затраг...,epic_fail, 11:08 , 04-Дек-12
    • Обновление MariaDB с устранением zero-day уязвимости, затраг...,Adui, 14:37 , 04-Дек-12
• Обновление MariaDB с устранением zero-day уязвимости, затраг...,Andrey Mitrofanov, 20:21 , 04-Дек-12

Oracle долго еще будет тянуть кота за яица^W хвост

Монти vs Oracle: 1:0 :)

Не долго осталось. Как мне помнится , когда Oracle скупила весь хабар у Sun
то она пообещала сопровождать MySQL до 2014 г. (где то на opennet.ru  была тогда про это новость ) Ну и нафига тратить силы на то, что ей и не надо ???

Глядишь, люди и поймут, что с мускуля пора бежать... и куда бежать - тоже ясно

Кому надо уже давно понял и свалил подальше от оракла. Остальные просто пользуются тем, что дает хостер.

Ну вот хостерам и будет понятно

> Глядишь, люди и поймут, что с мускуля пора бежать... и куда бежать - тоже ясно

И куда бежать? Во многих стабильных (и бинарных) дистрибутивах есть эта мариядб в репозиториях? В Ubuntu LTS я не нашёл...

>> Глядишь, люди и поймут, что с мускуля пора бежать... и куда бежать - тоже ясно
> И куда бежать? Во многих стабильных (и бинарных) дистрибутивах есть эта мариядб
> в репозиториях? В Ubuntu LTS я не нашёл...

Очевидно что на PostgreSQL.

> Очевидно что на PostgreSQL.

Нормально так: сбежать с повседневной легковушки на ... брутальный карьерный самосвал?

> сбежать с повседневной легковушки на ... брутальный карьерный самосвал?

Аноним, ты идиот.  PG это качественная легковушка (пусть будет иномарка), а mysql вообще не машина (ну или тазло в крайнем случае, т.е. ведро с гайками).

> PG это качественная легковушка (пусть будет иномарка), а
> mysql вообще не машина (ну или тазло в крайнем случае, т.е.
> ведро с гайками).

Такое сравнение ещё хуже, т.к. если у ведра отваливаются гайки, то его надо менять на более качественное ведро, а не таскать воду с колодца в качественной иномарке.

> т.к. если у ведра отваливаются гайки, то его надо менять на более качественное ведро

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

> вот в этом вся ваша сущность, адепты мускуля. А если у ведра
> гайки не отваливаются, то что, в нём тоже можно носить воду?

Ну при чём тут адепты мускула? Есть определённая программа со своими системными требованиями, в которых чёрным по белому написано - нужен мускуль. На постгресе она не поедет.

В таких случаях только адепты постгреса могут советовать переходить на него. И они же советуют ездить за водой на 10 метров без ведра, зато на машине.

> Есть определённая программа со своими системными требованиями, в которых чёрным по белому написано - нужен мускуль.

отлично. Но какое это отношение имеет к 'легковушка vs брутальный самосвал'?

ещё раз попрошу, заканчивай нести ерунду.

Простите, я думал это у вас просто аналогии такие дурацкие, и решил вернуть тему обратно в русло IT. А вы, оказывается, и вправду про машины с вёдрами говорили. Ок, больше не вмешиваюсь в ваши высокоинтеллектуальные размышления.

> Аноним, ты идиот.  PG это качественная легковушка (пусть будет иномарка), а
> mysql вообще не машина (ну или тазло в крайнем случае,

Не, не так. С точки зрения водителя карьерного самосвала или хотя-бы фуры, иномарка - вообще не машина! Как так: нельзя нагрузить тонну кирпичей или перевезти пару холодильников?! И куб грунта некуда девать. Не машина а жалкая пародия!

>> Очевидно что на PostgreSQL.
> Нормально так: сбежать с повседневной легковушки на ... брутальный карьерный самосвал?

Честно, я не понимаю этих глупых сравнений, по количеству потребляемых ресурсов как MySQL, так и PGSQL примерно равны, просто у постгреса больше функций, которые ты как можешь задействовать, так можешь и забить на них на начальном этапе. Если бы еще сравнивать например MySQL и Oracle или там MS SQL, да, аналогия имеет право на жизнь,  а так для маленьких проектов в принципе силы примерно равны, но зато у PostgreSQL есть огромный задел для дальнейшего роста, в отличии от MySQL, оптимизация производительности которой заканчивается мыслью "А не перейти ли нам на Percona?".

> Если бы еще сравнивать например MySQL и Oracle или там MS SQL, да, аналогия имеет право на жизнь,  а так для маленьких проектов в принципе силы примерно равны, но зато у PostgreSQL есть огромный задел для дальнейшего роста, в отличии от MySQL, оптимизация производительности которой заканчивается мыслью "А не перейти ли нам на Percona?".

+, всё так и есть.

всем наплевать на слона, слишком трудоемкий перезд для ленивых сиадминов

> всем наплевать на слона, слишком трудоемкий перезд для ленивых сиадминов

Ленивый сисадимн вымирает как класс

Только ленивый сисадмин может быть хорошим :)
Работодатели это к сожалению плохо понимают и предпочитают трудолюбивых обезьянок.

> Ленивый сисадимн вымирает как класс

Размечтался то. Тем более что хороший админ по определению ленив. Если админ усиленно рвет попу - это индикатор.

> всем наплевать на слона, слишком трудоемкий перезд для ленивых сиадминов

Отучайтесь говорить за всех.

большинству наплевать на ваши советы)

Переписывние кода под постгре стоит денег. А мария - drop-in replacement.

Все правильно говорите!!! :)

Если заказчик багач, можно и переписать

> багач

ну да, за «багачом» обычно много переписывать приходится.

> В Ubuntu LTS я не нашёл...

Жизнь заставит - найдете )

Подключайте репозитории. Percona тоже в офф. репах нету
https://downloads.mariadb.org/mariadb/repositories/

> Во многих стабильных (и бинарных) дистрибутивах есть эта мариядб в репозиториях?

В стабильных - да. См. openSUSE

На хостингах всё жизнь софт собирался руками

> Разработчик эксплоита не согласился с такой точкой зрения, указав, что получения прав "ADMIN" имея только права "FILE" не является штатным поведением;

+1. То ли разрабы просто ленятся, то ли им нравится вставлять палки в колёса  сисадминов.

Если зайти с другого боку - тот, кто дает права FILE пользователям (даже системным) на постоянку на боевом сервере - ССЗБ. В штатном режиме оное не нужно вообще.

> Если зайти с другого боку - тот, кто дает права FILE пользователям
> (даже системным) на постоянку на боевом сервере - ССЗБ. В штатном
> режиме оное не нужно вообще.

Это, конечно же, всё так, но в жизни ситуации бывают разные и я не вижу объективных причин нарочно подкладывать дополнительную свинью админам. Даже если они всё-равно ССЗБ.

ды не волнуйтесь вы так...

..исправят ваш FILE -- в каких нибудь там следующих мажорных версиях.

просто намякнули что нет смысла торопиться с *экстренным* исправлением, вот и всё.

откуда столько истерики?

Действительно, зачем нам скоростная выгрузка/загрузка данных, есть же mysqldump и мощные процессоры.

> Действительно, зачем нам скоростная выгрузка/загрузка данных, есть же mysqldump и мощные
> процессоры.

И куда вы столько раз вгружать-выгружать собрались, что нагрузка "без FILE" стала критичной? Может быть, лучше что-то сразу в канцелярии подправить?

Поставлена задача: "Две большие(ну скажем, пару часов на снятие дампа) БД с похожей, но отличающейся структурой, данные нужно регулярно синхронизировать в одном направлении. Нагрузку и трафик между серверами минимизировать"
Жду предложений по исправлению в канцелярии от титеретика.

Самый очевидный и правильный вариант для предложенной задачи:
mysqldump --host A | convert_dump | mysql --host B
К слову, использование FILE никак не вылечит от нагрузки/трафика. И от шага convert_dump не избавит, поскольку в задаче поставлена разная структура БД.

А вообще подобный идиотизм лечится грамотной statement-based репликацией в нужном направлении. Заметьте - репликацией возможно даже не на уровне MySQL. При этом нагрузка реально минимизируется. Если не хватает головы/рук чтобы такое сделать, и не мучать сервер дампами - ССЗБ.

У нас так (самописной репликацией) архивируется реалтаймовая база аккаунтинга, потому что если делать хоть дамп, хоть FILE - таскать 80-100 гиг каждые пару часов весьма невесело. Это я все к тому, что задача поставлена идиотская, и решать её "в лоб" (дампом) может только студент-"практик", который дальше шаблонов не идёт.

>mysqldump --host A | convert_dump | mysql --host B

Смешно

>И от шага convert_dump не избавит, поскольку в задаче поставлена разная структура БД

Избавит, ничего конвертировать не надо, вы бы хоть синтаксис "SELECT ... INTO OUTFILE"/"LOAD DATA INFILE" почитали

>А вообще подобный идиотизм лечится грамотной statement-based репликацией в нужном направлении.

Разная структура делает использование встроенного механизма репликации невозможным без наложения ряда ограничений. И это только на синхронизацию, использование вообще станет невозможным.

>таскать 80-100 гиг каждые пару часов весьма невесело

Мда, слово rsync никогда не слышали?

>репликацией возможно даже не на уровне MySQL
>У нас так (самописной репликацией)

Ну если есть куча свободного времени, то можно вообще мускул поправить или свою БД написать. А можно за полчаса получить результат используя уже имеющийся механизм.

>>И от шага convert_dump не избавит, поскольку в задаче поставлена разная структура БД
> Избавит, ничего конвертировать не надо, вы бы хоть синтаксис "SELECT ... INTO
> OUTFILE"/"LOAD DATA INFILE" почитали

Угу. Таки структура разная, или нет? Можно спросить - какой идиот разрабатывал схему БД?

> Разная структура делает использование встроенного механизма репликации

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

>>таскать 80-100 гиг каждые пару часов весьма невесело
> Мда, слово rsync никогда не слышали?

Т.е. предлагаете останавливать сервер на каждую подобную операцию?

> Ну если есть куча свободного времени, то можно вообще мускул поправить или
> свою БД написать. А можно за полчаса получить результат используя уже
> имеющийся механизм.

Смотря что за результат требуется. Если таскать болванки по 80-100 гиг каждые два часа, "минимизируя" нагрузку - ну... да. А если надо это все делать в реальном времени, тупо таская изменения по несколько десятков КБ, и действительно имея реалтаймовую синхронизацию - подходы совершенно другие.

Про "кучу свободного времени" и подходы есть вообще хороший, жизненный анекдот:
Идет мужик по деревне, видит, другой мужик ножиком дерево пилит. Ну, прошел. Через три часа идет назад - а тот мужик всё пилит, уже до половины допилил. Ну, идущий не выдержал - "мужик, чего мучаешься, пошли, я тебе пилу дам". А тот и отвечает: "некогда мне за твоей пилой ходить - когда я дерево-то пилить буду?".

> CVE-2012-5613 - не признана уязвимостью

В общем, логично.  FILE каждому раздавать не будешь...  А уж если раздал - не пускай в каталог данных mysql.

Все правильно объяснили:
http://seclists.org/oss-sec/2012/q4/394
- это от кривой конфигурации все.

> В общем, логично.  FILE каждому раздавать не будешь...  А уж
> если раздал - не пускай в каталог данных mysql.

А зачем БД по умолчанию их туда пускает?

А почему нет?  Для пользователя с правами администратора - это вполне имеет смысл.

> А почему нет?  Для пользователя с правами администратора - это вполне
> имеет смысл.

Пусть делают отдельную опцию и в документации напишут чем это опасно. Кому это действительно понадобится (а таких - меньшинство), те включат и будут точно знать зачем это надо и чем чревато.
А если это имеет смысл только для пользователей с правами "ADMIN", то зачем оно работает и для тех, у кого есть только "FILE", да ещё по умолчанию? В общем, с точки зрения сисадмина - полнейший бред.

> Пусть делают отдельную опцию и в документации напишут чем это опасно.

ага. а то админы — они такие: раздают права направо и налево.

>> Пусть делают отдельную опцию и в документации напишут чем это опасно.
> ага. а то админы — они такие: раздают права направо и налево.

Ну вот ты не путай админов с опытом и тех, кто только встает на данный путь. То что одному хорошо -- другому смерть )

а зачем оно лезет боевые сервера админить? пусть учится у старших сначала. а если полезло — то само виновато.

> ага. а то админы — они такие: раздают права направо и налево.

Да тут не важно - направо или налево. Просто любой нормальный человек, если ему понадобится что-то включить, то он это сделает и просто проверит - работает или нет. Если мне понадобится включить "FILE", то я его просто включу. И только если оно не заработает так как мне надо, тогда только полезу в документацию смотреть причины такого поведения.

А так, чтоб читать всю документацию от корки до корки и постоянно держать всё это в голове - я таких людей не встречал (так, чтоб ночью разбуди и он тебе расскажет, что если изменить такую-то опцию, то сломается вон там - совсем в другом месте - и чинить это надо вот так). И не надо отмазки лепить "а зачем оно лезет"; понадобилось, вот и полезло. Просто пишите так, чтоб было безопасно by design, и чтобы случайно отстрелить себе что-то было невозможно. Ведь сами же рано или поздно наткнётесь на эту или подобную подставу, ибо закон Мэрфи никто не отменял.

> Да тут не важно - направо или налево. Просто любой нормальный человек,

То нормальный человек. А нормальный сисадмин сначала прикинет, чем это ему грозит, и как на системе отразится.

>>> А так, чтоб читать всю документацию от корки до корки и постоянно держать всё это в голове - я таких людей не встречал

Блджад, печалька. А я каждый день в зеркале вижу. На самом деле - всегда сначала полностью прочесываю необходимые участки мануала (с нудным хождением по рефам, ага), и лишь потом (когда вся теория ясна и прозрачна, и в голове сложилась) берусь что-то собирать. Привычка.

Да. Медленнее... не намного, но медленнее "молодых и горячих". Факт. Зато потом не приходится жать плечами и биться головой об стену, что что-то работает не так, потому что "а вон ту фенечку надо было сразу вкрутить".

Сферические кони в вакууме это круто, но заглянем в реальный мир. Вот что есть в доке мускула про FILE privilege, расскажи с обоснованием какие проблемы ты видишь из этого текста, а самое главное, как отсюда следует обсуждаемый эксплойт.

The FILE privilege gives you permission to read and write files on the server host using the LOAD DATA INFILE and SELECT ... INTO OUTFILE statements and the LOAD_FILE() function. A user who has the FILE privilege can read any file on the server host that is either world-readable or readable by the MySQL server. (This implies the user can read any file in any database directory, because the server can access any of those files.) The FILE privilege also enables the user to create new files in any directory where the MySQL server has write access. As a security measure, the server will not overwrite existing files.

Не мечите бисер перед непогрешимыми всезнайками. Это у них по молодости, что быстро проходит.

> implies the user can read any file in any database directory

...
> privilege also enables the user to create new files in any
> directory where the MySQL server has write access. As a security

Этого уже достаточно, чтобы не включать данную привилегию.

Понятно, встретил слово security и испытал приступ медвежьей болезни. А так сладко пел про тщательное изучение.

> Да тут не важно — направо или налево. Просто любой нормальный человек,
> если ему понадобится что-то включить, то он это сделает и просто
> проверит — работает или нет. Если мне понадобится включить «FILE», то
> я его просто включу. И только если оно не заработает так
> как мне надо, тогда только полезу в документацию смотреть причины такого
> поведения.

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

Переход на личности? Не волнуйтесь, не вляпаетесь, моя компания IT-услуг не оказывает. Вернее - вляпываться будете постоянно (по своему опыту сужу), ибо такие крутые админы только в сказках обитают и работают только за соответствующую (сказочную) зарплату.

> Не волнуйтесь, не вляпаетесь, моя компания IT-услуг не оказывает.

счастье-то какое.

> А так, чтоб читать всю документацию от корки до корки и постоянно держать всё это в голове - я таких людей не встречал

вообще ты не прав. Админ, особенно ДБАшник, обязан это делать. Т.е. как минимум читать документацию по незнакомым моментам. Но чем проще и консистентнее дизайн системы, тем меньше шансов ошибиться, потому и

> Просто пишите так, чтоб было безопасно by design, и чтобы случайно отстрелить себе что-то было невозможно.

>> А так, чтоб читать всю документацию от корки до корки и постоянно держать всё это в голове - я таких людей не встречал
> вообще ты не прав. Админ, особенно ДБАшник, обязан это делать. Т.е. как
> минимум читать документацию по незнакомым моментам.

Вот признайтесь честно, кто знал про эту уязвимость или хотя бы про опцию secure-file-priv и что её надо обязательно включать и настраивать если кому-то даёте привилегии "FILE". Интересно, много таких? Задним-то умом мы все сильны.

причём тут, млять, "знал"? 'обязан узнать', особенно когда речь идёт о какой-то заведомо странной хренотени типа "FILE".

> причём тут, млять, "знал"? 'обязан узнать', особенно когда речь идёт о какой-то
> заведомо странной хренотени типа "FILE".

Ага, вот и начинается - не знал, но обязан узнать. Обязан, конечно, если тебе за это деньги платят. Вот только в документации про это - сюрприз - в ожидаемом месте ни слова:
http://dev.mysql.com/doc/refman/5.6/en/grant.html

И в описании про эту опцию тоже не особо много написано (это если ещё найдёшь её):
  --secure-file-priv=name
                      Limit LOAD DATA, SELECT ... OUTFILE, and LOAD_FILE() to
                      files within specified directory

Не, если постоянно админишь линуксы с мускулами, то наверняка такие вещи будешь знать и по-любому включишь эту опцию (опять же, если найдёшь) даже просто чтоб спокойней было. Если это твоя специализация. А если это студент на полставки 10 компов с виндами эникеет плюс сервер с сайтом компании? Жизнь ведь не чёрно-белая, она намного многообразнее.

ЗЫ: Нет, мне всё-таки стало очень интересно узнать - сколько людей из считающих, что CVE-2012-5613 не является уязвимостью (или считающих себя крутым админом), знали об этом подводном камне. Ну или если не знали за ненадобностью, то алгоритм ваших действий в случае если надо дать кому-то привилегии "FILE". - По пунктам: начну отсюда, потом почитаю там-то, и в конце включу такую-то опцию. Только чур честно.

> А если это студент на полставки 10 компов с виндами эникеет плюс сервер с
> сайтом компании?

то там столько дырок, что одной больше, одной меньше…

Дык, не удивительно. При таком то отношении разработчиков...

> Дык, не удивительно. При таком то отношении разработчиков…

каком «таком»? тебе в описании что написали? http://www.opennet.me/openforum/vsluhforumID3/87589.html#61
не ясно, чем это чревато? тогда да, разработчики забыли позаботиться об олигофренах.

>> ага. а то админы — они такие: раздают права направо и налево.
> Да тут не важно - направо или налево. Просто любой нормальный человек,
> если ему понадобится что-то включить, то он это сделает и просто
> проверит - работает или нет.

К счастью, в приличных местах таких "нормальных" апологетов метода тыка - гонят ссаной тряпкой.  Рано или поздно.

> А так, чтоб читать всю документацию от корки до корки и постоянно
> держать всё это в голове

"Постоянно держать все в голове" - не нужно.  Что нужно - прочитать документацию по опции полностью, раз уж собрался ей воспользоваться.  *Перед* включением.

В большинстве случаев file + sql injection = shell с правами web сервера.
Всяких вам творческих успехов с таким подходом к работе!

Если пользователям файлы заливать на сайт надо - тоже просто анонимный фтп доступ откроете в директорию сайта и пусть скрипты заливают? )

> В большинстве случаев file + sql injection = shell с правами web
> сервера.

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

И вообще-то изначально речь шла не про админов, а про программистов, которым лень исправлять уязвимости. Это потом набежали админы локалхостов, которым достаточно всретить слово security, чтобы наложить в штаны и никогда не использовать подобных привилегий.

>> А почему нет?  Для пользователя с правами администратора - это вполне
>> имеет смысл.
> Пусть делают отдельную опцию и в документации напишут чем это опасно.

Написали чем опасно.  Около уже существующей опции FILE.  Я даже выше ткнул носом местных "чукч" в пост.  

> Кому это действительно понадобится (а таких - меньшинство), те включат и будут
> точно знать зачем это надо и чем чревато.

Если сейчас эти буратины (не буду указывать пальцем) не сумели прочитать документацию по гранту FILE - почему тогда сумеют?

> В общем, с точки зрения сисадмина - полнейший бред.

А с точки зрения системного администратора - вполне нормальное и *документированное* поведение.

> Написали чем опасно.  Около уже существующей опции FILE.  Я даже
> выше ткнул носом местных "чукч" в пост.

http://dev.mysql.com/doc/refman/5.6/en/grant.html
Пальцем покажете где написано? А ведь это та самая страница, на которую я полезу почитать про эту опцию перед её включением. А ведь многие и туда не полезут, в лучшем случае на форумах прочитают готовую команду.

>> Кому это действительно понадобится (а таких - меньшинство), те включат и будут
>> точно знать зачем это надо и чем чревато.
> Если сейчас эти буратины (не буду указывать пальцем) не сумели прочитать документацию
> по гранту FILE - почему тогда сумеют?

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

>> В общем, с точки зрения сисадмина - полнейший бред.
> А с точки зрения системного администратора - вполне нормальное и *документированное* поведение.

Удачных поисков в документации (см. выше) и прокачке скиллов в определении мест, в которых разработчики подложили вам очередную свинью.
Задокументировать можно любую глупость, умнее и нормальнее она от этого не станет. А умные вещи, кстати, и без документации очевидны.

>А ведь это та самая страница, на которую я полезу почитать про эту опцию перед её включением.

Потому что де^Wчукча писатель, а не читатель.
На, читай. Сначала http://dev.mysql.com/doc/refman/5.6/en/privileges-provided.h... , после которого у админа должно начаться чесание задницы предвещающей неприятности потом сцылкой оттуда http://dev.mysql.com/doc/refman/5.6/en/string-functions.html... , где есть намек на то что попаболи можно избежать; и, уже http://dev.mysql.com/doc/refman/5.6/en/server-system-variabl...

Впрочем, если последний раздел админ не читал, то он уже не одмын и не чукча, а - дебил.

Минус за оскорбления.

Итак, подведём итоги. Чем опасна привилегия "FILE" (то, что я и просил показать, а не просто ссылку на опцию) - нигде не написано. О необходимости запрета доступа к папке с данными - не написано. О возможном повышении привилегий - не написано. Ссылка на нужную опцию находится в трёх кликах.

> Минус за оскорбления.

Коллеги, срач можно заканчивать.
Вот я - типичный быдлоадмин, если рассматривать меня, как DBA. Про уязвимости в мускуле узнал вот только сейчас, да и то, скорее - случайно.
Ради интереса полез поглядел права на десятке мелких серверов, File нет ни у кого, кроме root-a. Что логично: мускуль я рассматриваю как пассивное хранилище, само ничего не умеющее. И вообще, когда говорят о мускуле, быдлоадмин имеет в ввиду php+mysql. Ну или Perl/Python/...+mysql. Триггеры и хранимые процедуры на мускуле неудобны (сравниваю с другими БД), потому ими я особо и не пользуюсь, успешно заменяя скриптами на P...
Также интуитивно понятно, что File - "завышенная" привелегия, т.к.
1) Эта глобальная привелегия.
2) По дефолту юзер её не получает.
Ну и достаточно прочитать, что мы с этого имеем - доступ к файлам системы из БД, чтобы устрашиться (цена sql-injection повышается на порядок) и обойти стороной.

> Ну и достаточно прочитать, что мы с этого имеем - доступ к
> файлам системы из БД, чтобы устрашиться

как видишь, достаточно не всем: некоторые персонажи категорически отказываются включать мозг. уж не знаю, потому ли, что устройство дорогое, жалко лишний раз использовать, или по какой другой причине.

> Итак, подведём итоги. Чем опасна привилегия «FILE» (то, что я и просил
> показать, а не просто ссылку на опцию) — нигде не написано.

http://www.opennet.me/openforum/vsluhforumID3/87589.html#61

> О необходимости запрета доступа к папке с данными — не написано.

ЛОЛЩИТО? слушай, а если на сортире нет надписи «вытирайте задницу после процесса дефекации» — то задницу вытирать не надо, да?

>> Написали чем опасно.  Около уже существующей опции FILE.  Я даже
>> выше ткнул носом местных "чукч" в пост.
> http://dev.mysql.com/doc/refman/5.6/en/grant.html
> Пальцем покажете где написано? А ведь это та самая страница, на которую
> я полезу почитать про эту опцию перед её включением.

Вам ответили: #48.  Нет, к сожалению, в документации необходимого вам комикса или готового эксплойта - нету.  Головой таки нужно немного думать и о том как организована система прав в mysql - нужно знать, чтобы знать куда "лезть"...

Куда конкретно *вы* полезете - мне без разницы.

> А ведь многие и туда не полезут, в лучшем случае на форумах прочитают
> готовую команду.

Это просто менее продвинутые буратины, только и всего.

> А умные вещи, кстати, и без документации очевидны.

"Очевидно" только назначение мамкиной титьки.  Всему остальному документация - необходима.

emerge -C mysql && emerge -1 mariadb

достали!

Что все так прозрачно? Т.е. у MariaDB даже конфиг по дефолту такой же как у мускуля?

тюнинг у mariadb побольше, но они не утруждались файл конфигурации привести к продакшену

Мне одному показалось, что "zero-day" и "exploit", в частности, не совсем про эти уязвимости? Ну, значит, показалось.