マイナンバーのせいで、事務が増える・・・
・・・てのは、他人事ではない。
「ふるさと納税」の足引っ張るマイナンバー制
事務簡略化のはずが、自治体の作業が殺人的に
http://jbpress.ismedia.jp/articles/-/47845
・・・てのは、他人事ではない。
「ふるさと納税」の足引っ張るマイナンバー制
事務簡略化のはずが、自治体の作業が殺人的に
http://jbpress.ismedia.jp/articles/-/47845
前のエントリ
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インジェクションに話を膨らまされると、ちょっと面倒なのだ・・
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インジェクションに話を膨らまされると、ちょっと面倒なのだ・・
5.7系、5.6系、5.5系の全バージョンに、デフォルトで起こるそうな
SQLインジェクションを用いてリモートからmy.cnfファイルを変更できる
＋
mysqld_safeによるstartup時のライブラリのpreload機能
＝
任意のコードをroot権限で実行することが可能
ということらしい。
記事になっているのは、以下のサイト
MySQLに重大な脆弱性見つかる、パッチ存在せずデフォルトで影響
http://www.itmedia.co.jp/news/articles/1609/13/news055.html
この記事の写真にもある、脆弱性について詳しく書いたサイトが
http://legalhackers.com/advisories/MySQL-Exploit-Remote-Root-Code-Execution-Privesc-CVE-2016-6662.html
そこにあるように、「CVE-2016-6662」なので、ググる場合は、これで調べたほうが早い。
日本語では
MySQLでリモートからroot権限でファイルを実行できる脆弱性(CVE-2016-6662)
https://oss.sios.com/security/general-security-20160912
や
MｙSQL脆弱性 CVE-2016-6662 について (2016 09 13現在)
http://t-suzuki.hatenablog.jp/entry/2016/09/13/181555
SQLインジェクションを用いてリモートからmy.cnfファイルを変更できる
＋
mysqld_safeによるstartup時のライブラリのpreload機能
＝
任意のコードをroot権限で実行することが可能
ということらしい。
記事になっているのは、以下のサイト
MySQLに重大な脆弱性見つかる、パッチ存在せずデフォルトで影響
http://www.itmedia.co.jp/news/articles/1609/13/news055.html
この記事の写真にもある、脆弱性について詳しく書いたサイトが
http://legalhackers.com/advisories/MySQL-Exploit-Remote-Root-Code-Execution-Privesc-CVE-2016-6662.html
そこにあるように、「CVE-2016-6662」なので、ググる場合は、これで調べたほうが早い。
日本語では
MySQLでリモートからroot権限でファイルを実行できる脆弱性(CVE-2016-6662)
https://oss.sios.com/security/general-security-20160912
や
MｙSQL脆弱性 CVE-2016-6662 について (2016 09 13現在)
http://t-suzuki.hatenablog.jp/entry/2016/09/13/181555
アクセス
トータル
ランキング
