OpenSSLに脆弱性、0.9.7aと0.9.6iリリース 24
ストーリー by Oliver
なくならないのは必然か 部門より
なくならないのは必然か 部門より
iida 曰く、 "OpenSSLに脆弱性 が見つかったようだ。しかも0.9.6系、0.9.7系共通らしい。通常(?)の攻撃ならば、データ自体に細工をして戻ったデータの中身などを解析するのだろうが、ここでの脆弱性はデータの戻るまでの時間、いわばデータについての高次元データを計測し、それをもとに解読を試みるらしい。"
BSDのタレコミからの抜粋によると、" セキュリティホールmemoによると問題点は「MAC verification errorsを利用した攻撃には対応されておらず、タイミングベースの攻撃を受けてしまう」 とのことである。SSLの利用者は運用には十分注意し、早急に対応策を実施するべきだろう。FreeBSDの-STABLE及び-CURRENTへの組み込みにはあと数日が必要のようだ。"
FreeBSD -CURRENT (スコア:2, 参考になる)
には OpenSSL 0.9.7a が Wed Feb 19 23:10:53 2003 UTC に import [freebsd.org] されてます.
FreeBSD-STABLE (スコア:2, 参考になる)
早速アップデートしなきゃ。デモ、また明日。むにゃむにゃ。
Re:FreeBSD -CURRENT (スコア:1)
OPENSSH_OVERWRITE_BASE = yes
OPENSSL_OVERWRITE_BASE = yes
と、書いて ports でいれるようにしてます。
セキュリティーホールmemoはちょっと違う? (スコア:2, 興味深い)
タレコミで参照されてるセキュリティホールmemoでは
とありますが、 OpenSSL Security Advisory [openssl.org]の説明とは違いますね。 「block cipher padding errors」は 「MAC verification errors」と同じように扱われるが、 padding errorが検出されるとMAC verificationを行わないため、 エラーレスポンスが若干速く返るので、 それをモニターされてるとまずい、と理解しました。
Re:セキュリティーホールmemoはちょっと違う? (スコア:1, 興味深い)
ところで、padding errorなのかMAC verification errorsなのかがわかると何がマズいんでしょうか？
DoSに弱くなってでも秘匿すべき違いなんでしょうか？
教えて偉い人！
Re:セキュリティーホールmemoはちょっと違う? (スコア:2, 興味深い)
Re:セキュリティーホールmemoはちょっと違う? (スコア:1, 参考になる)
paddingが違うのかMACが違うのかわからなければ、どっちも試さなきゃ
だめじゃん。だからといって、これで早々に偽鍵が作れるわけじゃない
んだけどね。まあ理論値より弱くなることは事実だけど、だからといっ
てこの攻撃をしていると、ログにエラーが出まくってバレバレ。
Vulnerabilityは、Vulnerabilityなんだけど、だから何？みたいな。
それよりDoSになるって発想の方が、漏れ的には興味深い。
それにしても針小棒大に騒ぐ厨は2chより/.Jの方が多いね。興味深い...
Re:セキュリティーホールmemoはちょっと違う? (スコア:0)
ブロックに満たない所に埋めてるだけじゃん＞padding
そもそも、padding errorになるのはパケット捏造時に間違えてるだけで、padding errorなのかMAC verification errorsなのかがわかっても、それで得られる違いは
の、どちらかがわかるだけでは？
paddingが秘匿すべき情報となるのは、他人のパケットを傍受した場合で、このpaddingの値がわ
使える…の？ (スコア:2, 参考になる)
なるほど、今までフラグを見て gotoで処理をすっとばしてたところを、
フラグが真でも偽でも同じようなステップ数の処理を
行うようになった、と。
けど、実行するCPUが十分早ければ、
あるいは他の要素(ネットワークとか)が遅ければ、
この処理量の違いなんて簡単に埋もれてしまいそうなんですが、
どうなんでしょう？
Advisoryからリンクの張られているPassword Interception in a SSL/TLS Channel [lasecwww.epfl.ch]での実測では、
両者の時間の差は1000分の2秒程度しかないようなんですが...
Re:使える…の？ (スコア:2, 参考になる)
多分問題になるとしたら, ネットワークにおける延停が無視できる状況, 例えば同一LAN上で通信をモニタリングできるような組織内部からのクラックに対してでしょうね. 多分に理論的な弱点と考えて良いでしょう.
実務的には数10ms以上のレスポンス分散が有るWAN経由の接続ではまず問題になることは無いでしょうから, 至急対応が必要というよりも他に何かupdateの要件が有った場合についでに対応するという程度で大丈夫だと思います.
Re:使える…の？ (スコア:1)
あら／／／／／
対照性を仮定するだけのntpがミリ秒の精度で
同期できるのだから、レスポンス分散が100msec
程度であっても方法がないわけではないはずです。
オープンソースであるからこそ発見される脆弱性
ですよね？？ソース無しでこんな深い解析ができる
ものなのかなぁ／／／／
Re:使える…の？ (スコア:1)
ntpだと基本的に全て「当たり」なのでネットワークの延停を統計的に評価できますが, 今回の脆弱性だと「当たり」と「はずれ」が混在しているので統計的な評価が難しいと思います. つまりレスポンスが早かったのは「はずれ」だから早いのか, たまたまネットワークあるいはホストの負荷が低いから早いのかの区別がつかないってことです.
辞書攻撃みたいな場合に統計的なスクリーニング技法として補助的に使うことは出来るかもしれませんが, それとてレスポンスの分散が数10m秒以内に入っていないときついと思います.
またか・・・ (スコア:0)
これってSSLの理論？とかが難しいからなのでしょうか？
それとも実装者が・・・なのでしょうか？
（あとOpenSSHも多いなー）
Re:またか・・・ (スコア:0)
SSLでの通信ってことは、そもそも何か機密の必要な
データが流れている可能性が高いですから。
Re:またか・・・ (スコア:0)
IE, IISなどMS製品にセキュリティホールが多いのと同じ :-p
脆弱性 (スコア:0, 余計なもの)
Re:脆弱性 (スコア:1)
脆弱性というからには、一般にはバグのうちでも特に
セキュリティホールとなるバグのことを指していますが。
Vulnerability の日本語訳だし。
Re:脆弱性 (スレ違い:-1) (スコア:0)
「脆弱性」という言葉自体が抽象的すぎてわかりにくいだけでなく、セキュリティ上問題になりうるものであるという連想をしにくい、ということでしょう。
ニュアンス的なことなので人それぞれ感じ方が違うとは思うのですが、「性」を付けたことで言葉
Re:脆弱性 (スレ違い:-1) (スコア:1)
しょう。ある程度セキュリティに感心のある人間なら、知らな
いはずがない用語ですから。
> 「脆弱かもしれない、脆弱のような気がする」という曖昧な表現に思えます。
それは違います。一般性、人間性、必然性、など反例をあげる
までもなく、「性」という言葉を付け加えることによって意味
が弱まるなんてことはありません。
> 何らかの新しい用語定義をした方が良いのかもしれませんね。
新しい用語を作ることには反対です。親コメントのような人向
けに、初心者向け解説を加えることには賛成ですが、/. におい
てそんな説明が果して必要ですか？
もちろん、Microsoft のセキュリティ情報のコーナーや Windows
Update に書かれる説明が難しすぎる、ということを言っている
ならばその点には同意です。
感心 (スコア:0)
Re:脆弱性 (スレ違い:-1) (スコア:1)
しょうがないのですが
「脆弱である」 と 「脆弱性がある」 は意味が違うと思います。
たとえば、この脆弱性を内包したPCやらサーバーを持っているとします。（PCにしときましょう）
たしかにこのPCには弱点が存在するので
「脆弱性がある」という事はできます。
（リスクを内包しているという意味で）
ただし、持ってる人物が人間嫌いで無人島で一人で生活し、
もちろん他人と関わるのは嫌なのでネットワークに接続なんてしません。
という場合には「脆弱」でしょうか？
（そんな奴はPCも使わないとかいう突っ込みはナシの方向で）
誰も攻撃すらできないのですから、脆弱性はあっても脆弱ではないでしょう。
なので、この２つの言葉は利用する場面が違うはずなので
「脆弱性」で問題ないと思います。
----
もちろん、リスク自体を減らしたいので、私が管理しているサーバーには出来る限りパッチを当てております :-)
当てられないサーバー（業務データの載ってるMicrosoft SQLにパッチなんて怖くて出来ない）
もある事は理解しております。
Re:脆弱性 (スコア:0)
脆弱性は～解読を試みる、とつながっているあたりが変だと感じるのですが。
「バグを持つこと」が脆弱性だと思っていたのですが、バグ自体を脆弱性と呼ぶのですか？
脆弱と脆弱性の違いがよく分からなくなってきた・・
バグじゃない脆弱性 (スコア:1)
バグと脆弱性は別の物ですので, 分けて考えた方が良いでしょう. それではバグじゃない脆弱性って何かと言ったら, 良く聞くでしょう「仕様です」って.
有名な例はWEPですね. 一応, 仕様通りに暗号化されていますが, それが脆弱なため容易に破られてしまいます. まあ, これなんかは仕様バグと言ってもよいかもしれませんが. 他にも昔のNISの様にネットワーク上に暗号化したパスワードを流しちゃう, 今から見れば噴飯物の仕様もありますが, これもローカルの限られた範囲でのみ使うというのであれば大丈夫という判断もできます.
またWEPもそうですが, 暗号などでは定量的に安全性を評価することが必要です. 例えば64bit RC5が今日では既に脆弱であることが示されていますが, これも暗号化の為のbit長が短すぎるだけで原理的には問題は無いです.
もちろんバグによる脆弱性も多いのですが, 使用目的・環境がプログラムの想定していた物と異なるが故に脆弱性となってしまうことも多くあります(今回の指摘も若干その気が有るみたいです). ですから脆弱性が発見されたといっても単に騒ぐのではなく, それが自分のシステムに対してどのような影響を与えるのかを評価することが各自に要求されます.
Re:バグじゃない脆弱性 (スコア:1)
「脆弱性」という日本語は、いかにも翻訳調で不自然だと思うので、ぼくはたいてい「弱点」という言葉を使います。
もちろん100％言い換え可能というわけではありませんが。
鵜呑みにしてみる？