MySQLの脆弱性の問題に対する影響

前のエントリ

MySQLに重大な脆弱性見つかるが、パッチは１０月１８日に公開予定の件（それまで攻撃され放題？）
http://blog.goo.ne.jp/xmldtp/e/472ca926edfa7d11b3c592c210bf5e32

が、自分たちにどれだけの影響があるか、分かりにくいので、ちょっと細かく書く。

■現象

この現象は、以下の条件の「全てが成立」しないと「rootの乗っ取り」はできない。

（１）SQLインジェクションを使って、SELECT文で設定ファイルを書き出す
　→このバグは修正されている

（２）書き出すときに、logging関数を使う
　→つまりログとして書き出す。こうすると、上記修正の漏れをついて、
　　設定ファイルにできる

（３）設定ファイルに、mysqldで、悪意のあるライブラリを実行するように書き換える
　→そのライブラリが実行してしまう。

実際には、設定ファイル(my.cnf)が書き換えられると、もうwebサービスはとまるので、
（２）が出来た時点で、問題がある。

MｙSQL脆弱性 CVE-2016-6662 について (2016 09 13現在)
http://t-suzuki.hatenablog.jp/entry/2016/09/13/181555

の「今回の脆弱性」の「my.cnfに追記する」に、どういうSELECT文を流すとアウトなのか、
（コメントになっているけど）書いてある。

■とりあえずの対策
　上記「MｙSQL脆弱性 CVE-2016-6662 について (2016 09 13現在)」にもあるけど、
　設定ファイルを書き換えられなくすればよい。つまり、

・/etc/my.cnf がmysqlユーザで書き込み権限がないこと（例えば rootで 0644 ）を確認する
・/usr/local/mysql 直下が mysqlユーザの書き込み権限がないこと （例えば以下のようになっていること。mysqlユーザはここにmy.cnfを配置できない）を確認する

（太字は上記サイトより引用。具体的なコマンドも上記サイトにある）
を確認すれば言いだけなんだけど・・・

■話が発展してしまうと・・・

　SQLインジェクションを起こさなければいいじゃん！
　といわれると、そりゃーそうなんだけど、
　それ、調べますか・・・（＾＾；）

　いや、調べないといけないけど・・・

　で、そのとき、

「脆弱性があったとき、その責任は発注者？開発者－判決では開発者」という話を聞いてきた！
http://blog.goo.ne.jp/xmldtp/e/3a0b8abaacb7feab2a9d1646735d8f44

に書いたように、SQLインジェクションが起こった場合の責任は、
「お客様がSQLインジェクション対策しろと言っていなくても」
開発者側の責任になることがある（善管注意義務）
なので・・・SQLインジェクションに話を膨らまされると、ちょっと面倒なのだ・・