Debianのopensslパッケージに欠陥発覚 80
ストーリー by nabeshin
SourceForge.JPユーザーも対応を 部門より
SourceForge.JPユーザーも対応を 部門より
iida 曰く
Debianで運用しているSourceForge.JPでもアップデートパッケージを適用している。アナウンスにあるように、ユーザーの方で該当のクライアント鍵を使っていた場合はSSHログインができない。その場合は鍵ペアを作り直して再登録していただきたい。Debian GNU/Linuxで、0.9.8c-1以降のopensslパッケージに 欠陥が発覚し、修正版パッケージがリリースされた。なお、オリジナルのOpenSSLにこの欠陥はない。
パッケージの再導入が必要なことは当然だが、欠陥を内包したopensslコマンドで生成した鍵は廃棄し、再生成すべき点が重要。Debianのページによれば、とのこと。DebianやUbuntuなどの管理者、利用者は要注意だ。影響を受ける鍵は、SSH鍵、OpenVPN鍵、DNSSEC鍵、X.509証明書を生成するのに使われる鍵データ、および SSL/TLSコネクションに使うセッション鍵です。GnuPGやGnuTLSで生成した鍵は影響を受けません。
他のOSの利用者も安心できない (スコア:5, すばらしい洞察)
Re:他のOSの利用者も安心できない (スコア:2, 参考になる)
（朝出る前に急ぎで書いたので、ちょっとわかりづらい表現になってしまっているかも。改善案求む）
なぜ？ (スコア:2, 興味深い)
説明がないのでさっぱり。
で、チェックするスクリプト(及び鍵)
http://security.debian.org/project/extra/dowkd/dowkd.pl.gz
http://security.debian.org/project/extra/dowkd/dowkd.pl.gz.asc
やらを紹介されているが、どう使ってどういう結果が出れば
NG なのか説明がないのでさっぱり。
対象マシンで
% ./dowkd.pl user
と実行したけど、何も表示されなかったから OK ってこと？
さっぱりだ。
Re:なぜ？ (スコア:5, 参考になる)
OpenSSL パッケージの脆弱性とその影響について (SSH鍵、SSL証明書等） [debian.or.jp]の方を見るが吉。
ナイス・フォロー (スコア:1, おもしろおかしい)
> Sarge までの Debian で生成したSSL証明書は今回の問題の影響を受けません。
なんだ、大丈夫だった。
マテ、いつまで同じ鍵を使ってるんだ俺。
Re: (スコア:0)
Re:ナイス・フォロー (スコア:1)
Re: (スコア:0)
sargeで生成した鍵は問題ないってことでしょ。
Re:ナイス・フォロー (スコア:2, 参考になる)
もっとも、鍵長や重要度によっては、鍵更新を検討した方がいいって場合もあるでしょうけど。
Re:境界条件 (スコア:1, すばらしい洞察)
とは限らない、あるいは絶対に間違いや取り違いや勘違いが起きないようにしたい [google.com]からこそ「冗長にする」のでは
特に数字以外のものに以上や以下が使われるときは、境界値の扱いは書き手も受け手もかなり適当なことがある
Re:なぜ？ (スコア:1, すばらしい洞察)
その段階でパッチの誤りが発覚したかもしれないのにねぇ
バグフィックスのつもりでエンバグした挙げ句に
フィードバックもしないとは、酷すぎるな
Re:なぜ？ (スコア:1, 参考になる)
ほれ。 [mail-archive.com]
Re:なぜ？ (スコア:1)
それは酷すぎる!!
Best regards, でぃーすけ
assert 消す奴も (スコア:1)
「あんたのせいでバグが増えた、テストもできん」
って怒られた。assert() でチェックせずにテストに回して
あれこれ謎の不具合が見つかるほうが非効率的だと思うのだが。
そして俺の assert() タンはコメントアウトされた。
＃ぜってーおかしいって、その assert() が通らんのは
屍体メモ [windy.cx]
Re:assert 消す奴も (スコア:1)
> あれこれ謎の不具合が見つかるほうが非効率的だと思うのだが。
確かに。
assert()は自動で行う「テスト」ですよね。想像ですが本件は、単体試験を行わずに結合試験やるようなものですね。
Best regards, でぃーすけ
Writing Solid Code (スコア:1)
自分なりに assert って大事だよな、って肌で感じてましたけど、
大学生のときに Writing Solid Code [amazon.co.jp] って本を読んで、
改めて assert の大切さを認識しました。
やっぱりマイクロソフトも泥臭い苦労してるんだなぁ、と親近感を覚えました。
屍体メモ [windy.cx]
Re:なぜ？ (スコア:1)
$ dpkg -L openssh-client
/.
/usr
/usr/lib
/usr/lib/openssh
/usr/lib/openssh/ssh-keysign
/usr/bin
/usr/bin/ssh-copy-id
/usr/bin/ssh
/usr/bin/ssh-agent
/usr/bin/scp
/usr/bin/ssh-keyscan
/usr/bin/ssh-argv0
/usr/bin/ssh-add
/usr/bin/sftp
/usr/bin/ssh-keygen
/usr/bin/ssh-vulnkey
/usr/share
/usr/share/doc
/usr/share/doc/openssh-client
/usr/share/doc/openssh-client/changelog.Debian.gz
/usr/share/doc/openssh-client/README.compromised-keys.gz
/usr/share/doc/openssh-client/README
/usr/share/doc/openssh-client/NEWS.Debian.gz
/usr/share/doc/openssh-client/README.dns
/usr/share/doc/openssh-client/README.tun.gz
/usr/share/doc/openssh-client/copyright
/usr/share/doc/openssh-client/changelog.gz
/usr/share/doc/openssh-client/README.Debian.gz
/usr/share/doc/openssh-client/OVERVIEW.gz
(snip)
$ dpkg -s openssh-client
Package: openssh-client
Status: install ok installed
Priority: standard
Section: net
Installed-Size: 1608
Maintainer: Matthew Vernon <matthew@debian.org>
Architecture: i386
Source: openssh
Version: 1:4.3p2-9etch1
Replaces: ssh, ssh-krb5
Provides: rsh-client, ssh-client
Depends: libc6 (>= 2.3.6-6), libcomerr2 (>= 1.33-3), libedit2 (>= 2.5.cvs.20010821-1), libkrb53 (>= 1.4.2), libncurses5 (>= 5.4-5), libssl0.9.8 (>= 0.9.8c-1), zlib1g (>= 1:1.2.1), debconf (>= 1.2.0) | debconf-2.0, adduser (>= 3.10), dpkg (>= 1.7.0), passwd, libssl0.9.8 (>= 0.9.8c-4etch3)
Suggests: ssh-askpass, xbase-clients
Conflicts: ssh (<< 1:3.8.1p1-9), sftp, rsh-client (<< 0.16.1-1), ssh-krb5 (<< 1:4.3p2-7)
(snip)
Re:なぜ？ (スコア:1)
通常であれば、buildd のログを見て確認できるのですが、security アップデートだと通常とは違う経路で build されているかもしれません。
http://security.debian.org/pool/updates/main/o/openssh/ も見ましたが、パッケージが存在していないですね。
確認すべき場合は、debian-arm@lists.debian.org か debian-security@lists.debian.org に投げてみると良いかと。
＃もし、必要でしたら聞いてみるぐらいは明日してみますよ。
arm でも build されました＞玄箱/Proユーザの方 (スコア:1)
Re:arm でも build されました＞玄箱/Proユーザの方 (スコア:1)
とんでもないです、むしろ状況を教えていただけて情報がシェアできるのでありがたいです（arm マシンを使って無いので当方では全く気づいていませんでした）。感謝します。
Re:なぜ？ (スコア:1)
% perl ~/Downloads/dowkd.pl user
summary: keys found: 3, weak keys: 0
なので、何も表示されないのは動作がおかしいのでは？もし改行がないせいで何も表示しないように見えているなら、
% ./dowkd.pl user; echo
とやってみてはどうでしょうか?
Best regards, でぃーすけ
これはやばい (スコア:2, 参考になる)
・SSHワームが現れる。Debianの当該バージョンで生成した公開鍵を登録しているサイトが軒並み侵入され、ボットネットに編入される。Webサイトの場合はウイルスを埋め込まれる。
・某認証局の中間CA証明書の鍵がDebianの当該バージョンで作成されていたことが攻撃者に先に知られ、偽のWebサイト証明書が大量に作成され、フィッシングサイト多発。当該CAをrevoke。当該CA発行の証明書を使っていたサイトが軒並み証明書の再発行手続きに追われる騒ぎに。
・Debianの当該バージョンで生成したサーバ証明書で運用中のSSLサイトのリストが晒しあげられる。いつまでたっても直らないとニュースになる。
Re:全く大変（Re:これはやばい） (スコア:1)
＃…ま、実際は公開鍵認証使ってないから、取り合えず大丈夫なんですけどね。でも盗聴が防げない。（＜SSHの意味がない）
# mishimaは本田透先生を熱烈に応援しています
実家鯖ガクブル (スコア:2, 興味深い)
とりあえずケーブル抜いてもらっているのだけど，何が起こっていたのかわからず，
次に実家に帰る時までどうしようもない．ああ，どうなってるんだ～気になる．
sarge のときから鍵はそのままだったような気もするし，更新した気もするし・・
動的IPアドレスでDynamic DNSを使っているからその更新遅れかもしれないけど，
再びケーブル刺してもらうのも怖いし．
屍体メモ [windy.cx]
Re:実家鯖ガクブル (スコア:1)
アタックをしかけた結果、攻撃先のサーバーがたまたま
本件の脆弱な鍵を使っていて、かつ短時間で鍵を割り出せて
侵入できたーというのは可能性としては非常に低いと思われますね。
以前から総当り攻撃を受けていて、たまたまこのタイミングで
鍵が分かっちゃったというのも可能性としては低い。
仮にその場合、侵入されるまでに攻撃元からのアクセスを拒否する等、
対策を取らなかったことがまずいけど。
もしかして、脆弱性のニュースをキャッチして危険を感じたらssh
ポートを閉じてしまうような賢いAIでも搭載していましたか?
いや、sshデーモンが自我に目覚めて反乱を起こしたということも……
既にexpolit codeがあります (スコア:4, 参考になる)
Debian generated SSH-Keys working exploit [securityfocus.com]
既にexploit codeがBUGTRAQに流れています。最新のopenssh-serverパッケージ であれば危険なホスト鍵を使っていたら自動的に置き換えるのである程度は安心ですが、 アップグレードができているかどうかは確認しましょう。
新しいパッケージ openssh-blacklist(危険な乱数列のリスト)が必要となるので、dist-upgradeでないと 置き換わりません。その点ご注意を。
ZDNet Japan Blog - 日本Linux協会blog：OpenSSL問題その後 [zdnet.com]にも解説してあります。
knok
Re:実家鯖ガクブル (スコア:2, すばらしい洞察)
そんなんで済むんならセキュリティなんていらないよねー。
Re:実家鯖ガクブル (スコア:1)
外部公開サーバなのにSSHでrootログイン可能で、しかもその鍵をsargeで生成、なんてのが最も危険なパターンなのかな？
＃そんな悪い子は/.Jにはいないと思いますが…
DoS対策はしてたので (スコア:1)
設定をしていたので，総当たりするとなると何日もかかると思うんだよな・・
となると，単にハードディスクがクラッシュしたか！
って，それはそれでえらいこっちゃ．
屍体メモ [windy.cx]
Debianだけではない (スコア:1, 参考になる)
（例：Ubuntu）
Re:Debianだけではない (スコア:3, 参考になる)
影響のあるリリース：
* Ubuntu 7.04 (Feisty)
* Ubuntu 7.10 (Gutsy)
* Ubuntu 8.04 LTS (Hardy)
* Ubuntu "Intrepid Ibex" (development): libssl <= 0.9.8g-8
* Debian 4.0 (etch) (see corresponding Debian security advisory)
Re:Debianだけではない (スコア:1)
＃さっさと当てちまったのでよく判らん。
Re:Debianだけではない (スコア:1, 参考になる)
http://www.debian.org/security/2008/dsa-1571 [debian.org]
>この欠陥を持つ最初のバージョンは 0.9.8c-1 で、不安定版に 2006-09-17 にアップロードされており、その後テスト版 (testing) や安定版 (etch) に流れています。旧安定版 (sarge) には影響はありません。
2006年末に出たKNOPPIX5.1以降なら×だろうが、手元にあったKNOPPIX-4.0.2-20050923-20051116+IPAFontとか、KNOPPX Hacks(2005年06月発行)に入ってるKNOPPIX-3.8日本語版は多分大丈夫だろう(2006年6月に日本語版の出たKNOPPIX5.0.1も同じ)。
もっとも、openssh やら何やらの脆弱性が塞がってない可能性を考えると、どのバージョンもNetを挟んだ暗号化通信は基本的にダメといってもいいかも。
Re:Debianだけではない (スコア:1)
5.1.3はDVD用のイメージしかなかったので、やってません。
KNOPPIX方面からのアナウンスってないでしょう??
対策（パッケージアップデート） (スコア:1, 興味深い)
問題ないの？
Re:対策（パッケージアップデート） (スコア:1, 参考になる)
openssh-server のパッケージアップデート中に既存の通信は切断されません。 (スコア:1)
Debianのパッケージ作成が発見を遅らせた？ (スコア:1, 興味深い)
ほかにもあるんじゃないの？この手のミス
X.509 の鍵のチェックをする方法はないの？ (スコア:1)
SSLの鍵についても作り直しをしなければならないのがかなり厳しい。
SSH なんて、ほとんどの場合サーバ管理者にしか関係ないけど、
SSL だとWebアプリ全般に関わってくるんだぜ…
で、サーバ証明書取り直さなきゃいけないとなると予算が…
近所ではクライアント証明書ぜんぶ再発行＆CAの作り直しの話をしてる…
＃これから数日の間にSSL証明書を切り替えるサイトには注目してください。
＃その中には、Debian 使いがいるかもしれないのだから…
# mishimaは本田透先生を熱烈に応援しています
X.509 の鍵についても調べる方法がわかりました (スコア:1)
ただし、Debian と Ubuntu では openssl のバージョンが異なるのでインストール時にエラーになる。
debian/control の中の Depends: をいじって debuild したら、うまく使えるようになりました。
# こういうことができるようになったのも Debian 勉強会のおかげです
# mishimaは本田透先生を熱烈に応援しています
DSA鍵はさらに注意が必要 (スコア:1, 参考になる)
DSA鍵の場合は、署名等に使用したシステムが脆弱なら生成された署名から秘密鍵が類推できるものと思われます。 例えば、Sargeで生成したDSA鍵をEtchにアップグレードした後も署名に使っているとかいう場合に その署名が悪意あるものの手に渡ったら元のDSA鍵が暴かれてしまうということのようです。
Re:DSA鍵はさらに注意が必要 (スコア:2)
いまいち何のことをいっているのかよくわかりませんが、Sargeで生成されたssh鍵や OpenSSLの証明書を使っている分には、危険はありませんよ。
問題があるのは、危険な乱数生成アルゴリズムで作成された公開鍵・秘密鍵のペアを 使うことなので、OpenSSLが安全だったころに作った証明書が持つ公開鍵・暗号鍵や、 sshの鍵には問題ありません。
knok
いやしかし (スコア:0)
Re:いやしかし (スコア:2, 参考になる)
# これくらいその関数内のコード追っかけるだけで分かるのに、ほんとに何やってんだか。
本来はアプリケーション側がランダムなデータを用意してssleay_rand_add()に食わせてランダム性を 確保するようになっています。そこをコメントアウトしたので全くランダム性が失われていたのです。
原因は、valgrind使ったアプリケーションが本当にタコで未初期化のバッファを渡していたか、 パッチ作成者が悪意を持ってパッチを書いたか、でしょう。
Re:いやしかし (スコア:2, 参考になる)
OpenSSL内部で未初期化のバッファを渡している部分があるという指摘がありました。
http://www.links.org/?p=328 [links.org]
しかしOpenSSLが未初期化のバッファに依存しないということには変わりありません。
上述のページには「何が問題だったか」と「今後どうすべきか」がまとめてありますので、詳しく知りたい方は是非読んでみてください。
そもそもDebianは充分なセキュリティを備えていないんだから (スコア:0, すばらしい洞察)
Re:そもそもDebianは充分なセキュリティを備えていないんだから (スコア:2, すばらしい洞察)
なんかセキュリティホール関連のアナウンスが多い気がするね。
利用者が比較的多いからなのか、他のディストリでもおきてるけど表にでてきてないだけなのか。
Re:そもそもDebianは充分なセキュリティを備えていないんだから (スコア:2, 興味深い)
まあ、リアルファイアウォールを突破 [srad.jp]されたディストリはDebianぐらいだと思われ。
Re:そもそもDebianは充分なセキュリティを備えていないんだから (スコア:1, 参考になる)
Re:SSLサーバ証明書 (スコア:2)
「--rand」じゃなく「-rand」ですね、ってのはさておき、興味深いコメント [slashdot.jp]にあるリンク [debian.org]をたどって読むと、rand/md_rand.cのssleay_rand_add関数に当てたパッチがまずかったらしい。
この関数ですが、「openssl genrsa -rand ファイル 」を実行したとき、RAND_SSLeay関数経由で、呼ばれるときがあるように見えます。というのは、OPENSSL_NO_ENGINEマクロを定義してコンパイルすると、RAND_SSLeay関数で乱数を作るよう、実行時に設定されますが、このマクロなしでコンパイルすると、SSLのエンジンにしたがった関数のアドレスが戻ることもあるわけです。
Debianでどちらでコンパイルされていたか定かではないですが、《エンジンなし》と考えるのが妥当かと思います。 とすると、RAND_SSLeay関数から、ダメダメなssleay_rand_addが関数が呼ばれて、-randの引数が捨てられる、という嬉しくない展開になりそうな気がします。
仮定も入ってますし、(最近あまりC読んでないので) 大間違いをやらかしてるかもしれませんが、ご参考までに。
iida