アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
クラックを法規制強化で止められると思ってる奴は頭がおかしい -- あるアレゲ人
何があったんだろ？ (スコア:2, 興味深い)
ついこのあいだ0.9.8cが出たばかりで、今度は同時に4件のセキュリティアップデイト。
妙に多い更新に、
FIPS認定が取り下げられたから、再チャレンジに向けて張り切っているんだろうか。
とか、
かなり使い込まれてるから、こういった危険性は少ないのかと思ってたけど、OpenSSLってまだまだ危ない所が残っているという事だろうか。
とか、色々考えてしまいます。
Re:何があったんだろ？ (スコア:2, おもしろおかしい)
0.9.8cは実はpublicベータ版で、
本当はバージョン1にも満たないソフトウェアだったんだよ!
# 注)ネタですから
Re:何があったんだろ？ (スコア:2, 興味深い)
いやいや、ネタとは言い切れないかもしれませんよ。
OpenSSLの実装は、いわゆる「脆弱性」に強いようには見えませんが。「強いように見えない」理由は。
・C言語で書いてある
・char buf[256];のようにふつーに固定バッファリングが残ってる
ヨワヨワとまではいいませんし、「脆弱性」が絶対なくならないとはいいませんけど。
でも、ちょっと難しい気が。。。
そういう印象批評は良くないと思います (スコア:3, 参考になる)
あることが潜在的な脆弱性と言うなら、Linuxや*BSD
などの多くのUnix系OS、Apacheなどのサーバーデーモン
など、殆どのプログラムが脆弱性を孕んでいることに
なりませんか。そして、最早それはC言語で書いた
プログラムは脆弱だという非現実的な議論に
なりませんか？
C言語でプログラムを書く場合には、
スタック上にこういうバッファを取るのと
必要なメモリーをライブラリーに確保してもらうのとは
バッファーオーバーラン攻撃を受けるリスクと
メモリーリークを内包するリスクを天秤にかけて
判断することで、必ずしも後者が良いとは思いません。
後者は副作用を持つので、場合によっては嫌われる
スタイルになるのではないでしょうか。
さらに言うなれば、
この手の脆弱性はstack smashingを防ぐ仕組みが
あればかなり防げるので、w^xやexec-shieldのような
ものの実装が当たり前になれば今後はあまり大きな
問題にはならないように思います。
さりとて、DoS攻撃できるポイントに変わるだけですが。