Am 12.09.2016 um 20:25 schrieb Sergei Golubchik:

Hi, Alex!

On Sep 12, Alex wrote:

...

Hello,

In regards to this zero day remote exploit , it seems MariaDB is also affected. Percona seems to have released new versions out to fix this. Any news from MariaDB side ?

http://legalhackers.com/advisories/MySQL-Exploit-Remote-Root-Code-Execution-...

Yes, it was https://jira.mariadb.org/browse/MDEV-10465, fixed in 5.5.51, 10.0.27, 10.1.17, all released last month

thanks but "MySQL-Exploit-Remote-Root-Code-Execution" is written by fools - how would a mysqld running as restricted user get root-privileges without any additional kernel-bug and who right in his mind is running mysqld as root where with port 3306 it donÄt need that privileges even for startup? [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/mysqld.service [Unit] Description=MariaDB Database Before=postfix.service dovecot.service dbmail-imapd.service dbmail-lmtpd.service dbmail-pop3d.service dbmail-timsieved.service [Service] Type=simple User=mysql Group=mysql ExecStart=/usr/libexec/mysqld --defaults-file=/etc/my.cnf --pid-file=/dev/null ExecStartPost=/usr/libexec/mysqld-wait-ready $MAINPID Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 TimeoutSec=300 LimitNOFILE=infinity LimitMEMLOCK=infinity OOMScoreAdjust=-1000 TasksMax=2048 PrivateTmp=yes PrivateDevices=yes NoNewPrivileges=yes CapabilityBoundingSet=~CAP_AUDIT_CONTROL CAP_AUDIT_WRITE CAP_DAC_OVERRIDE CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID CAP_SYS_ADMIN CAP_SYS_BOOT CAP_SYS_MODULE CAP_SYS_PTRACE SystemCallFilter=~acct modify_ldt add_key adjtimex clock_adjtime delete_module fanotify_init finit_module get_mempolicy init_module kcmp kexec_load keyctl lookup_dcookie mbind mount open_by_handle_at perf_event_open pivot_root process_vm_readv process_vm_writev ptrace request_key set_mempolicy swapoff swapon umount2 uselib vmsplice RestrictAddressFamilies=AF_UNIX AF_LOCAL AF_INET AF_INET6 SystemCallArchitectures=x86-64 ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr ReadOnlyDirectories=/var/lib ReadWriteDirectories=/var/lib/mysql

Am 12.09.2016 um 21:40 schrieb Alex:

Not sure , based from http://news.softpedia.com/news/mysql-zero-day-allows-database-takeover-50821... , it says this:

"CVE-2016-6662 allows attackers to alter the my.conf file

where does the mysql user have that permissions?

and load third-party code that will be executed with root privileges

hwo should that be possible from a daemon runnign with a restricted user?

The second vulnerability Golunski discovered, which he didn't make public, is CVE-2016-6663. This is a variation of CVE-2016-6662, also leading to remote code execution under a root user"

don't matter, see above

On 9/12/2016 10:17 PM, Reindl Harald wrote:

...

Am 12.09.2016 um 20:25 schrieb Sergei Golubchik:

...

Hi, Alex!

On Sep 12, Alex wrote:

...

Hello,

In regards to this zero day remote exploit , it seems MariaDB is also affected. Percona seems to have released new versions out to fix this. Any news from MariaDB side ?

http://legalhackers.com/advisories/MySQL-Exploit-Remote-Root-Code-Execution-...

Yes, it was https://jira.mariadb.org/browse/MDEV-10465, fixed in 5.5.51, 10.0.27, 10.1.17, all released last month

thanks

but "MySQL-Exploit-Remote-Root-Code-Execution" is written by fools - how would a mysqld running as restricted user get root-privileges without any additional kernel-bug and who right in his mind is running mysqld as root where with port 3306 it donÄt need that privileges even for startup?

[root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/mysqld.service [Unit] Description=MariaDB Database Before=postfix.service dovecot.service dbmail-imapd.service dbmail-lmtpd.service dbmail-pop3d.service dbmail-timsieved.service

[Service] Type=simple User=mysql Group=mysql ExecStart=/usr/libexec/mysqld --defaults-file=/etc/my.cnf --pid-file=/dev/null ExecStartPost=/usr/libexec/mysqld-wait-ready $MAINPID Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 TimeoutSec=300 LimitNOFILE=infinity LimitMEMLOCK=infinity OOMScoreAdjust=-1000 TasksMax=2048

PrivateTmp=yes PrivateDevices=yes NoNewPrivileges=yes CapabilityBoundingSet=~CAP_AUDIT_CONTROL CAP_AUDIT_WRITE CAP_DAC_OVERRIDE CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID CAP_SYS_ADMIN CAP_SYS_BOOT CAP_SYS_MODULE CAP_SYS_PTRACE SystemCallFilter=~acct modify_ldt add_key adjtimex clock_adjtime delete_module fanotify_init finit_module get_mempolicy init_module kcmp kexec_load keyctl lookup_dcookie mbind mount open_by_handle_at perf_event_open pivot_root process_vm_readv process_vm_writev ptrace request_key set_mempolicy swapoff swapon umount2 uselib vmsplice RestrictAddressFamilies=AF_UNIX AF_LOCAL AF_INET AF_INET6 SystemCallArchitectures=x86-64

ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr ReadOnlyDirectories=/var/lib ReadWriteDirectories=/var/lib/mysql

Am 12.09.2016 um 22:53 schrieb Reinis Rozitis:

...

how should that be possible from a daemon runnign with a restricted user?

Some distros run mysqld_safe under root which also reads the *.cnf files (cowered in advisory)

mysqld_safe != mysqld != something a client interacts with which distribution out there is running *mysqld* as root?

Am 12.09.2016 um 23:28 schrieb jocelyn fournier:

Le 12/09/2016 à 23:18, Reindl Harald a écrit :

...

Am 12.09.2016 um 22:53 schrieb Reinis Rozitis:

...

...

how should that be possible from a daemon runnign with a restricted user?

Some distros run mysqld_safe under root which also reads the *.cnf files (cowered in advisory)

mysqld_safe != mysqld != something a client interacts with which distribution out there is running *mysqld* as root?

The mysqld flaw (running as mysql) allows changes to the my.cnf to add a LD_PRELOAD which will load the mysql_hookandroot.so as root thanks to mysqld_safe, at the next mysql restart

on which linux distribution is "my.cnf" writeable by the user the daemon runs under?

Am 12.09.2016 um 23:38 schrieb Reinis Rozitis:

...

mysqld_safe != mysqld != something a client interacts with which distribution out there is running *mysqld* as root?

Did you read the advisory or I don't get what your are arguing against/for?

A client interacts with a database which in some cases using simple SQL is able to overwrite configuration files which then might be used a by a safeguarding script (been there for ages). Further disclosure might explain how it can be done even without FILE or SUPER privileges.

a service itself *must not* have the permissions to write it's config files

...

but "MySQL-Exploit-Remote-Root-Code-Execution" is written by fools

If you call someone a fool for disclosing such an attack vector (which is aknowledged by all sides (the software developers / Mitre etc)) even if as you think doesn't affect you is quite rude

"Root-Code-Execution" is clickbait

Am 12.09.2016 um 23:58 schrieb Reinis Rozitis:

...

a service itself *must not* have the permissions to write it's config files

The safeguard script also reads configuration files from MySQLs data directory which is writable by the service

[root@srv-rhsoft:~]$ cat /etc/passwd | grep mysql mysql:x:27:27:MySQL Server:/dev/null:/usr/sbin/nologin "mysqld_safe" is deleted from packages for 5 years here

Though the author also cowers cases of bad configuration and possible victims.

...

"Root-Code-Execution" is clickbait

Since when a CVE is a clickbait ..

the "Root-Code-Execution" part is maybe someone consideres throw away "mysqld_safe" and stops starting it as root anyways since for high ports root permissions where *never* needed __________________________________ * this below does the same as "mysqld_safe" way cleaner * it restarts mysqld if it crashs * it don't contain obscure shell scripts * systemd don't need pid-files for tracking type=simple * "mysqld-wait-ready" makes sure depedning service are started after the dameon is fully opertional * no bit of mysql is running as root __________________________________ [Service] Type=simple User=mysql Group=mysql ExecStart=/usr/libexec/mysqld --defaults-file=/etc/my.cnf --pid-file=/dev/null ExecStartPost=/usr/libexec/mysqld-wait-ready $MAINPID Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 __________________________________ [root@srv-rhsoft:~]$ cat /usr/libexec/mysqld-wait-ready #!/usr/bin/bash # Service file passes us the daemon's PID daemon_pid="$1" # Wait for the server to come up or for the mysqld process to disappear ret=0 while /usr/bin/true; do RESPONSE=`/usr/bin/mysqladmin --defaults-file=/etc/my.cnf --socket=/var/lib/mysql/mysql.sock --user=UNKNOWN_MYSQL_USER ping 2>&1` mret=$? if [ $mret -eq 0 ]; then break fi # exit codes 1, 11 (EXIT_CANNOT_CONNECT_TO_SERVICE) are expected, # anything else suggests a configuration error if [ $mret -ne 1 -a $mret -ne 11 ]; then ret=1 break fi # "Access denied" also means the server is alive echo "$RESPONSE" | grep -q "Access denied for user" && break # Check process still exists if ! /usr/bin/kill -0 $daemon_pid 2>/dev/null; then ret=1 break fi usleep 100000 done exit $ret

Am 12.09.2016 um 23:58 schrieb Alex:

From what i noticed , centos6 hosts that were on mysql 5.6 , or mariadb 10.1.17 is using the mysqld_safe. Upgraded centos7 hosts , and mysqld_safe is no longer a running process for mariadb 10.1.17.

Would this mean that only the hosts that do not run the mysqld_safe are safe ?

maybe https://bugzilla.redhat.com/show_bug.cgi?id=714426#c31

On 9/12/2016 9:25 PM, Sergei Golubchik wrote:

...

Hi, Alex!

On Sep 12, Alex wrote:

...

Hello,

In regards to this zero day remote exploit , it seems MariaDB is also affected. Percona seems to have released new versions out to fix this. Any news from MariaDB side ?

http://legalhackers.com/advisories/MySQL-Exploit-Remote-Root-Code-Execution-...

Yes, it was https://jira.mariadb.org/browse/MDEV-10465, fixed in 5.5.51, 10.0.27, 10.1.17, all released last month