MySQL/MariaDBにバグ、256分の1の確率で間違ったパスワードでも認証されてしまう 42
ストーリー by hylom
これは危ない 部門より
これは危ない 部門より
あるAnonymous Coward 曰く、
特定のバージョンのMySQLおよびMariaDBにおいて、「256分の1の確率で、パスワードが間違っていたとしてもパスワード認証を突破できてしまうう」バグが発見された（SecLists.Org、SecManiac）。
このバグを使用すると、300回程度のアクセスを試みるだけでrootを含む任意のユーザーでのログインが可能であり、事実上パスワード認証が意味を成さなくなってしまうとのこと。
ただしこれらの影響を受けるビルドは少なく、多くの公式ベンダが提供するビルドでは問題はないそうだ。
対象となるMariaDBおよびMySQLのバージョンは5.1.61、5.2.11、5.3.5、5.5.2。こただしこの問題が発生するか否かはmemcmpの実装によって異なり、GCCビルトインのものやBSDのlibcのものについては安全だが、LinuxのSSE最適版glibcに含まれるmemcmpについては安全ではないそうだ。GCCは通常最適化のためにGCCビルトインのmemcmpを利用するとのことで、またMySQLおよびMariaDBが提供しているオフィシャルなバイナリについてもこの脆弱性の影響は受けないとのこと。
256発か…… (スコア:1)
バグというよりバキュラだな。
Re:256発か……（オフトピ:-1） (スコア:1)
ご存知の通り本家バキュラは256発 [wikipedia.org]では壊れません。その理由についてまたぎきレベルで納得したのですが当時のH/Wでは敵キャラ1つずつに256発分の記憶域なんて持てないからだそうです。
# その後、256発で壊れるのは名高い続編の [wikipedia.org]やあんなのやこんなの [yahoo.co.jp]がありますよねー
Re:256発か……（オフトピ:-1） (スコア:1)
本人のブログでFAQとして解説されてますよ。
http://ameblo.jp/evezoo/entry-10105919686.html [ameblo.jp]
> 当時のH/Wでは敵キャラ1つずつに256発分の記憶域なんて持てないからだそうです。
いや、さすがにそんなことは…
単に、そういう仕様じゃないってだけでは。
# 「256発分の記憶域」って何バイトだと思ってるのか気になる...
Re: (スコア:0)
敵キャラ１つにつき1バイト程度のメモリ誤差の範囲だろと思われているということは、お若いんでしょうねえ
# ジジイの繰り言なのでAC
Re: (スコア:0)
ゼビウス世代の基盤はそこまで厳しくないでしょう。
Z80を3発搭載の豪華仕様なんだから。
Re: (スコア:0)
やっぱり極上パロディウスの16bitバキュラだろ
Re: (スコア:0)
そもそもゼビウスには固い敵はいなかったような。
アンドアジェネシスだって各コアの耐久力は1発ですよ？
パッケージされたものたち (スコア:1)
最近のサイ○ウズさんのＤＢは自社製になったんでしたっけ？
昔はMySQLだったような、おぼろげな記憶が・・・
Re:パッケージされたものたち (スコア:1)
Gar**n 最新版も MySQL ですよ。
恐ろしい・・・ (スコア:1)
phpMyAdminをパブリックにしてた日には自殺モンだな
Re: (スコア:0)
そこでベーシック認証もさせての二重ログイン方式ですよwww
というかレンタルサーバの場合SSHなんかのログインは出来ないでMySQLの管理は
phpMyAdminで管理する方式が一般的な気がするけど
Re: (スコア:0)
今となってはVPSが格安(ワンコイン)で利用でき、SSHつながらない共用レンタルサーバーは超初心者用です。
自分は昔 htaccessでIPアドレス絞ってphpMyAdmin使ってたな。IPアドレス変わったらsshつないでhtaccess書き換えて・・・
Re: (スコア:0)
VPS管理保守がめんどくさい。
フルマネージメントにすると価格が・・・・
>自分は昔 htaccessでIPアドレス絞ってphpMyAdmin使ってたな。IPアドレス変わったらsshつないでhtaccess書き換えて・・・
それこそ仕事で使っているなら固定IP取得しておけと
Ubuntu linux でアップデート (スコア:1)
ＭｙＳＱＬのアップテートがあったけど
この問題かな？
Re:Ubuntu linux でアップデート (スコア:1)
1/256 (スコア:0)
すぐにけせすぐにけせすぐにけせ
どういう (スコア:0)
実装なのか想像するスレ
Re:どういう (スコア:5, 参考になる)
昨日twitter上でいろいろと話していました。えーっと…
1. memcmp は、通常、差異がある場合は先頭バイトの差を返す(-255～255)
2. ところが SIMD 命令などで memcmp が最適化された場合、char の範囲外(int範囲とか)になってしまう可能性がある。
3. その戻り値を char にキャストしているため、場合によっては下位 8bit が 0 になって、一致してしまう。
てなことらしい。たぶん。
Re:どういう (スコア:1)
先頭バイト値の差だとしても、既にchar型の範囲外だね。char型は-128〜127
というより、関数の戻り値がintなのにcharにキャストしてしまっている時点で、ただのバグだね。
SSE最適化とかは本質的には関係ないな。
Re:どういう (スコア:1)
自己レス失礼。
理解した。
-255〜255だと、元が0でなきゃchar型にキャストしても0にならない範囲内なのね。
これは確かにうっかりしそうだ。
それでも縮小キャストしてる時点で終わってますが。
Re: (スコア:0)
しかもその理由が「コンパイラが警告を出すから」だったりするし。
Re: (スコア:0)
ナローキャストしないと警告を出すなんて!?
と思ったが、こういうことだな。
char型を返す関数内でmemcpy関数の戻り値を引き回した。
intからcharへの暗黙のナローキャストが発生しているので、コンパイラが警告を出した。
明示的にキャストを追加したら警告が出なくなった。（明示的なキャストは「わかっててやってる」はずのものなので）
幸せになったつもりが、不幸せになっていた。
Re:どういう (スコア:2, 参考になる)
"Because of incorrect casting" と書いてありますね。
memcmp の戻り値を char に変換した上で 0 と比較してるんじゃないでしょうか。memcmp の戻り値は、一致の場合0、違う場合は正または負の整数ですが、0じゃない整数を char に変換すると 1/256 の確率で 0 になって一致したことになると。この場合、戻り値の整数値に 1 または -1 しか使わないような実装の memcmp なら問題は生じないので、実装によっては大丈夫という理由も説明できます。
Re:どういう (スコア:1)
未初期化変数返してるんじゃないかな。
一致した時だけ0を入れてて、そうでないときは何もしてないとか。
スルースキル：Lv2
Keep It Simple, Stupid!
Re: (スコア:0)
typedef char BOOL;
とかやってるとはまりそうですね。
Re: (スコア:0)
SSE最適化版のみってことだからマルチバイトで比較して memcmp から結果を返す前に char にキャストしてんじゃないかな。
Re: (スコア:0)
わざわざ、なんでキャスト？っておもってみたら
charを返す関数でmemcmpの戻り値そのままreturnで返してるんですね。
こんなキャストなら俺もミスするかも
Re: (スコア:0)
それキャストじゃなくて暗黙の型変換じゃん。型変換を何でもかんでもキャストと呼ぶバカは爆発しろ。ってMySQLの開発者が言ってんのか。深刻すぎる
300回? (スコア:0)
どういう根拠で出した数字だろ。
まさか分母より少し大きめなら当たるだろ、程度の根拠かな。
n回の試行で当たる確率は全部外れる確率を1から引いたもの。1-(1-当たる確率)^n。
300回じゃ7割弱なのだが。
Re:300回? (スコア:1)
0x00～0xFF(正確には0x0…0～0xF…Fの256通り)のどれかでバグが再現するため、1/256と言うことでしょう。
＃この手のバグの場合、純粋な確率論で話を進めてもあまり意味がないと思うよ
Re:300回? (スコア:4, 参考になる)
多分元コメが言ってるのは、
「1/256で突破できるものに対し、『300回程度のアクセスを試みるだけで』って言い方はどこから出てきたんだ？」
という点でしょ？
元コメが書いてるように、1/256で当たりが出るものに300回挑戦しても70%程度の確率でしか当たりは引けない。なんで300で線引きするの？という疑問だと思う。
#でもまあ元コメの言いたいことも、タレコミでだいたい300と書いたのも、どちらも理解は出来るが。
おまけ。
当たりを引く確率が90%ぐらいになるのは589回、99%ぐらいになるのは1177回ぐらい。
Re: (スコア:0)
うん。確率が1/256なのはわかるよ？
わからないのは300回の試行で通るところなんだけど。
Re: (スコア:0)
元が
~300 attempts takes only a fraction of second, so ...
なんで、まぁあまり深く考えるのは無駄かと
Re:300回? (スコア:2)
原文は、
> ~300 attempts takes only a fraction of second, so basically account password protection is as good as nonexistent.
> 300回の試行にはわずか数分の1秒しかかからないため、アカウントのパスワードによる保護はあってないようなものである。
ですよね。300回の試行がごく短時間でできると言っているだけで、やはり
「300回程度のアクセスを試みるだけでrootを含む任意のユーザーでのログインが可能であり」というのは間違いです。
300回の試行なんて一瞬だから当たる確率が99%になる1200回の試行も
数秒で終わるため、簡単に突破されてしまう、というのならわかります。
Re: (スコア:0)
これって完全ランダムなくじびき状態なの？ それならその通りだと思うけど
Re: (スコア:0)
この場合は確率といってもランダムで当たるわけじゃないから、
２５６回やれば１００％じゃないの。
Re: (スコア:0)
9998まではいったのだが…
Re: (スコア:0)
あーる乙。
Re: (スコア:0)
それは「256回目までの試行で当たる確率が100％」であって
確率が1/256とはまた違うよ。
Re: (スコア:0)
値がランダムかどうか分からないですね。
値のばらつきぐあいが、環境に依存するかも知れないし。
与えたパスワードに依存するのなら、うまく考えた256個のパスワードがあれば、
どれかは当たるということになりますね。
SQL (スコア:0)
つまりこれは、PostgreSQLを使いなさいと言うことですね。
>LinuxのSSE最適版glibcに含まれるmemcmpについては安全ではないそうだ
この関係の問題だとするとglibcそのものに問題があってMySQL意外にも
セキュリティー的な問題が出そうなソフトがまだ出てくる可能性はあるって事ですよね?
Re:SQL (スコア:3, 参考になる)
タレコミの書き方が悪いんだが、#2172313 [srad.jp]のツリーを読む限りでは、MySQLのキャストミスが原因。glibcは悪くない。