アカウント名:
パスワード:
今回の件がなぜ発生するか、ネットでの書き込みをいくつかまとめてみました：
> ユーザーがMariaDB/MySQLに接続する場合、トークン（パスワードとランダムスクランブル文字列上のSHA）を計算し> 期待値と比較。memcmp()は通常、比較対象をcharと見做して比較し、差異があった先頭バイトの差を返すので> -127～127の範囲の値が返る。ところが、GCCの持っているSSE最適化されたmemcmp()は、このレンジ外の値を返すため、> 今回の脆弱性にヒットする。プロトコル上ランダムな文字列を使用しているが、このバグでログインできちゃう確率は> 約1/256と高い。>> ただし、GCCは通常SSE最適化されたmemcmp()を使用しないので、多くのMySQLバイナリはこの脆弱性の影響を受けない。> たとえば、gccでコンパイルしている場合で通常のSSE最適化されたmemcmp()、BSD libcのmemcmp()を使用時は問題が> 起きない。Linux/glibcのSSE最適化されたgccは上記の懸念があるが先に記したように先行して問題が回避されて> いるはず。> 本事案はどちらかというと公式ベンダーMySQLとMariaDBバイナリは脆弱ではありません。> それよりもMariaDB/MySQLの特定ビルドの脆弱性、導入方法と場所等のほうが危険性が増します。
参考文献> https://twitter.com/kossetsu_inryo/status/212457163107475456 [twitter.com]> https://twitter.com/kossetsu_inryo/status/212457333761126402 [twitter.com]> http://news.ycombinator.com/item?id=4093996 [ycombinator.com]
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
なぜ起きるかのまとめ： (スコア:2)
今回の件がなぜ発生するか、ネットでの書き込みをいくつかまとめてみました：
> ユーザーがMariaDB/MySQLに接続する場合、トークン（パスワードとランダムスクランブル文字列上のSHA）を計算し
> 期待値と比較。memcmp()は通常、比較対象をcharと見做して比較し、差異があった先頭バイトの差を返すので
> -127～127の範囲の値が返る。ところが、GCCの持っているSSE最適化されたmemcmp()は、このレンジ外の値を返すため、
> 今回の脆弱性にヒットする。プロトコル上ランダムな文字列を使用しているが、このバグでログインできちゃう確率は
> 約1/256と高い。
>
> ただし、GCCは通常SSE最適化されたmemcmp()を使用しないので、多くのMySQLバイナリはこの脆弱性の影響を受けない。
> たとえば、gccでコンパイルしている場合で通常のSSE最適化されたmemcmp()、BSD libcのmemcmp()を使用時は問題が
> 起きない。Linux/glibcのSSE最適化されたgccは上記の懸念があるが先に記したように先行して問題が回避されて
> いるはず。
> 本事案はどちらかというと公式ベンダーMySQLとMariaDBバイナリは脆弱ではありません。
> それよりもMariaDB/MySQLの特定ビルドの脆弱性、導入方法と場所等のほうが危険性が増します。
参考文献
> https://twitter.com/kossetsu_inryo/status/212457163107475456 [twitter.com]
> https://twitter.com/kossetsu_inryo/status/212457333761126402 [twitter.com]
> http://news.ycombinator.com/item?id=4093996 [ycombinator.com]
( ´・ω・`)いままでとこれからを比べる生活
ぱんかれ