Preface

接近第一時間的時候稍微追了一下漏洞的 PoC，
雖然離事件發生也隔了好幾天了，
還是整理成一篇文章紀錄一下，
畢竟應該是今年最大的漏洞了吧？

Note

漏洞的詳細細節都在以下這個文件：
http://legalhackers.com/advisories/MySQL-Exploit-Remote-Root-Code-Execution-Privesc-CVE-2016-6662.html
以下稍微紀錄之前追的時候看到的東西

這邊可以看到 MySQL 全部的版本都中獎了，
然後連 MariaDB 跟 PerconaDB 也中獎。

從 PoC 可以看到，
是透過 mysqld_safe 這個 wrapper script 來作為攻擊點。

即便 mysqld 不是以 root 的權限執行，
MySQL 預設仍會讓 mysqld_safe 這個 wrapper script 以 root 的權限執行。
然後 mysqld_safe 裡頭有個 set_malloc_lib 的 function 可以用來 preload shared library，
至於要 preload 什麼 shared library 可以透過執行 mysqld 時加入 --malloc-lib=$LIB
或是在 my.cnf 的 mysqld 或 mysqld_safe 的 section 中指定路徑。

如果攻擊者將惡意的 shared library 上傳到目標伺服器，
然後再將 my.cnf 中的 preload library 路徑改到該惡意的 shared library 的路徑，
則目標伺服器下次重新啟動 mysql 的時候，
就會載入該惡意的 shared library，
讓攻擊者達到執行任意程式碼的攻擊，
而且是以 root 的身份執行，
因為是由 mysqld_safe load 進來的。

今年 7 月 29 日通報 Oracle、MariaDB、PerconaDB。
後兩者已於今年 8 月 30 日修補漏洞，新的版本中不會有此漏洞。（所以我說 Oracle 呢？）

目前仍然沒有官方補丁可用。
一旦有補丁釋出，使用者應該儘快更新。

暫時的解法是確認 mysql 這個 user 沒有任何 MySQL 的設定檔的 owner 權限，
然後建立一個只有 root 有 owner 權限的 my.cnf 的備份檔，
這部份應該就是在 my.cnf 真的被改掉的話，可以回復回來。

似乎還有一個 0-day CVE-2016-2663 不過好像還沒公佈細節

覺得整個攻擊的手法挺有趣的，
概念不難理解，
但可行性因為必須先注入惡意的 shared library 還要把 my.cnf 的 lib 路徑改掉，
然後還要重新啟動才會生效而大大降低，
反而平常沒在更新就不需要重啟的 MySQL server 不會出事。
但可行性低不代表不會發生，
個人覺得可能會出現在 APT 那種針對性的攻擊吧。

丟在 gist 上備份一下 https://gist.github.com/M157q/a3c14b99905f3d3704b2477fb47cd33a

Related Links

• http://legalhackers.com/advisories/MySQL-Exploit-Remote-Root-Code-Execution-Privesc-CVE-2016-6662.html
• MySQL 全系列的安全性漏洞 | Gea-Suan Lin's BLOG
• Percona Server Critical Update CVE-2016-6662 - Percona Database Performance Blog
• New MySQL Zero Days — Hacking Website Databases