アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、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攻撃できるポイントに変わるだけですが。
Re:何があったんだろ？ (スコア:0)
とか言ってもマイナスモデ食らうのが今のスラドクオリティだろうな。
いや、邪魔したね。スコア5でも貰うといいと思うよ