インフィニティソリューションズ株式会社ブログ

続報:MySQLのパスワード脆弱性

MySQLのパスワードに残る脆弱性についての紹介ではイマイチ中身が良く分からなかったが、Rapid7Security Streetにもう少し詳しく出ていたので、紹介する。

A Tragically Comedic Security Flaw in MySQL(悲しいほどこっけいなMySQLのセキュリティ・ホール)

Sample Program

‘On Saturday afternoon Sergei Golubchik posted to the oss-sec mailing list about a recently patched security flaw (CVE-2012-2122) in the MySQL and MariaDB database servers. This flaw was rooted in an assumption that the memcmp() function would always return a value within the range -128 to 127 (signed character). On some platforms and with certain optimizations enabled, this routine can return values outside of this range, eventually causing the code that compares a hashed password to sometimes return true even when the wrong password is specified. Since the authentication protocol generates a different hash each time this comparison is done, there is a 1 in 256 chance that ANY password would be accepted for authentication.’

「土曜日の午後、Sergei Golubchik氏がMySQLとMariDBデータベースサーバのセキュリティホールに対する最近のパッチ(CVE-2012-2122)についてOss-secのメーリングリストにポストした。この欠陥はmemcmp()関数の戻り値が常に-128から127までの値であると想定していることが根本原因だ。プラットフォームによって、またある最適化が有効になっていると、このルーチンの戻り値が、その範囲外になる場合がある。その結果、ハッシュパスワードを比較するコードが、間違ったパスワードを指定されても、正と判断してしまうことがある。認証プロトコルは、この比較が行われる旅に、異なるハッシュを生成するため、1/256の確率で、いかなるパスワードでも認証されてしまう可能性がある。」

— memcmp()というのはCのメモリブロックを比較する関数で、マニュアルを見る限り、戻り値は、0、正の整数、負の整数のいずれかとしか書いていないようだ。勝手に範囲を決めて、しかもその範囲を超えた時のことを考慮していないのはお粗末。

‘In short, if you try to authenticate to a MySQL server affected by this flaw, there is a chance it will accept your password even if the wrong one was supplied. The following one-liner in bash will provide access to an affected MySQL server as the root user account, without actually knowing the password.’

「簡単に言えば、この欠陥に影響を受けるMySQLサーバに対し認証を試みれば、間違ったパスワードでも認証される可能性があるということ。以下のbashの1行でパスワードを知らずとも、そのMySQLサーバにルートユーザでアクセスできてしまう。」

$ for i in `seq 1 1000`; do mysql -u root –password=bad -h 127.0.0.1 2>/dev/null; done

mysql>

‘According to Sergei, this is normally not the case, and the routine is normally compiled into the server as an inline function. The major exception is when GCC uses SSE optimization.’

「Sergei氏によると、通常はこの(戻り値が想定の範囲を超える)ようなことは起こらず、またこのルーチンは通常インライン関数としてサーバに組み込まれているとのこと。主たる例外は、GCCがSSE最適化を使用している場合だ。」

脆弱性の存在が確認されているプラットフォームについては、この記事と前回紹介しているところと変わらない。非脆弱性が確認されたプラットフォームのリストは以下の通り。

  • Official builds from MySQL and MariaDB (including Windows)
  • Red Hat Enterprise Linux 4, 5, and 6 (confirmed by Red Hat)
  • CentOS using official RHEL rpms
  • Ubuntu Linux 32-bit (10.04, 11.10, 12.04, likely all)
  • Debian Linux 6.0.3 64-bit (Version 14.14 Distrib 5.5.18)
  • Debian Linux lenny 32-bit 5.0.51a-24+lenny5 ( via @matthewbloch)
  • Debian Linux lenny 64-bit 5.0.51a-24+lenny5 ( via @matthewbloch)
  • Debian Linux lenny 64-bit 5.1.51-1-log ( via @matthewbloch)
  • Debian Linux squeeze 64-bit 5.1.49-3-log ( via @matthewbloch)
  • Debian Linux squeeze 32-bit 5.1.61-0+squeeze1 ( via @matthewbloch)
  • Debian Linux squeeze 64-bit 5.1.61-0+squeeze1 ( via @matthewbloch)
  • Gentoo 64-bit 5.1.62-r1 ( via @twit4c)
  • SuSE 9.3 i586 MySQL 4.1.10a ( via @twit4c)
  • OpenIndiana oi_151a4 5.1.37 ( via @TamberP)
  • FreeBSD 64-bit (many versions)

脆弱性が存在するのかどうかは、サンプルプログラムを実行して確認するのが最も確実だとのこと。試しに、Ubuntu 11.10でやってみた。

その結果は、

Vulnerable! memcmp returned: –150

なるほど。是非チェックをお薦めする。