aboutsummaryrefslogtreecommitdiffstats
path: root/japanese/security/2008/dsa-1576.wml
blob: faea5da67d929b9bcec7b23aa53ae450cdef8000 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
#use wml::debian::translation-check translation="b128ca5f062ffd92dfde8a7b5888d4e87ec075f2"
<define-tag description>予測可能な乱数生成器</define-tag>
<define-tag moreinfo>
<p>昨日公開された Debian の openssl パッケージの更新
(<a href="/security/2008/dsa-1571">DSA-1571-1</a>, <a href="https://security-tracker.debian.org/tracker/CVE-2008-0166">CVE-2008-0166</a>)
 は、OpenSSH にも間接的に影響します。この結果、壊れたバージョンの
Openssl で生成された全てのユーザとホスト鍵は、openssl の更新適用後も信用
できないものとして扱われなければなりません。</p>

<p>1. セキュリティ更新をインストールする</p>

   <p>この更新は openssl の更新済みのパッケージに依存関係を指定していますの
   で、自動的に修正済の libssl0.9.8 パッケージと、新パッケージ
   openssh-blacklist がインストールされます。</p>

   <p>更新の適用が終わったならば、可能な場合には脆弱なユーザ鍵は自動的に拒
   絶されます。但し全部の検出は行えません。ユーザの個人認証にこのような
   鍵を使っている場合は、鍵は直後に動作しなくなり、新しい鍵で更新しなけ
   ればならなくなります (第三節参照)。</p>

   <p>OpenSSH ホスト鍵は、OpenSSH セキュリティ更新を適用後自動的に再作成さ
   れます。更新時には、この処理の前にユーザへの確認問い合わせが行われま
   す。</p>

<p>2. OpenSSH の known_hosts ファイルを更新する</p>

   <p>ホスト鍵を再生成した場合、SSH を使っているシステムに接続の際、
   known_hosts のホスト鍵の更新がすんでいない場合には以下の警告画面が表
   示されます。</p>

<pre>
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
</pre>

   <p>この場合、単にホスト鍵が変更されているので、エラーメッセージにあるよ
   うに対象の known_hosts を更新する必要があります。</p>

   <p>サーバ鍵の交換には、信用できる通信路を使用することを勧めます。鍵はサ
   ーバ上の /etc/ssh/ssh_host_rsa_key.pub に置かれます。鍵のフィンガー
   プリントは以下のコマンドで見ることができます。</p>

      <p>ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub</p>

   <p>ユーザ別の known_hosts ファイル以外に、システム全体で有効なホストフ
   ァイル  /etc/ssh/ssh_known_hosts が存在しているかもしれません。このファ
   イルは ssh クライアントと sshd の両方で hosts.equiv 機能を提供するた
   めに使われています。このファイルも同様に更新する必要があります。</p>

<p>3. 全ての OpenSSH ユーザ鍵をチェックする</p>

   <p>一番安全な手順は、欠陥のないシステムで作成された鍵だと強く確信できる
   場合を除いて全ての OpenSSH 鍵を再作成することです。</p>

   <p>鍵が安全かどうかは、この更新に含まれている ssh-vulnkey ツールでチ
   ェックできます。既定では、ssh-vulnkey はユーザ鍵の標準の格納場所
   (~/.ssh/id_rsa, ~/.ssh/id_dsa と ~/.ssh/identity) と、authorized_keys
   ファイル (~/.ssh/authorized_keys と ~/.ssh/authorized_keys2)、およ
   びシステムのホスト鍵 (/etc/ssh/ssh_host_dsa_key と
   /etc/ssh/ssh_host_rsa_key) をチェックします。</p>

   <p>自分の全ての鍵が標準の場所 (~/.ssh/id_rsa, ~/.ssh/id_dsa, または
   ~/.ssh/identity) に格納されている場合、それらをチェックするには以下
   のコマンドを使います。</p>

     <p>ssh-vulnkey</p>

   <p>システムの全ての鍵をチェックするには</p>

     <p>sudo ssh-vulnkey -a</p>

   <p>非標準の場所での鍵をチェックするには</p>

     <p>ssh-vulnkey /path/to/key</p>

   <p>もし ssh-vulnkey が "Unknown (no blacklist information)" と答えた場
   合、キーが脆弱かどうかの情報がないということです。この場合には、ファ
   イルの修正時刻 (mtime) を ls -l を使って調べると良いでしょう。2006
   9月以前に作成された鍵には欠陥はありません。可能性は低いですが、バッ
   クアップ処理でファイルの日付が戻されているかもしてない、またはシステ
   ム時刻の設定が正しくなかったかもしれない、などは頭に入れておいてくだ
   さい。</p>
   
   <p>疑わしい場合は、新しい鍵を作成して、全部のサーバから古い鍵を削除して
   ください。</p>

<p>4. 影響するユーザ鍵を再生成する</p>

   <p>ユーザの個人認証に使用する OpenSSH 鍵は、手動で再生成する必要があり
   ます。これは生成後に他のシステムに移動した鍵を含みます。</p>

   <p>新しい鍵は ssh-keygen を使って作成します。</p>

<pre>
   $ ssh-keygen
   Generating public/private rsa key pair.
   Enter file in which to save the key (/home/user/.ssh/id_rsa):
   Enter passphrase (empty for no passphrase):
   Enter same passphrase again:
   Your identification has been saved in /home/user/.ssh/id_rsa.
   Your public key has been saved in /home/user/.ssh/id_rsa.pub.
   The key fingerprint is:
   00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 user@host
</pre>

<p>5. authorized_keys ファイルを更新する (必要に応じて実行)</p>

   <p>ユーザキーを再作成した後、対応する公開鍵は必要なリモートシステムの
   authorized_keys (または authorized_keys2) に配布する必要があります。
   当該ファイルから古い鍵を削除することを忘れないようにしてください。</p>


<p>乱数の欠陥への対処のほかに、この OpenSSH の更新では幾つかのそれ以外の欠
陥も修正しています。</p>

<p><a href="https://security-tracker.debian.org/tracker/CVE-2008-1483">CVE-2008-1483</a>:
   Timo Juhani Lindfors さんにより、X11 フォワーディングを行っている場
   合、SSH クライアントが X11 フォワーディングポートを、そのポートが全
   てのアドレスファミリで用いられていることを確認せず利用していることが
   発見されました。システムが IPv6 を用いるように設定されている場合 (有
   効な IPv6 接続を持っていない場合でも)、リモートサーバ上の攻撃者が
   X11 フォワーディングをハイジャック可能です。</p>

<p><a href="https://security-tracker.debian.org/tracker/CVE-2007-4752">CVE-2007-4752</a>:
   Jan Pechanec さんにより、ssh が信用できない X11 クッキーの作成に失敗
   した場合に、信用された X11 クッキーの作成にフォールバックするようになっており、X11
   フォワーディングを行っている場合に悪意を持ったリモートサーバにローカ
   ルの表示情報が漏洩する可能性があることが発見されました。</p>

<p>安定版 (stable) ディストリビューション (etch) では、これらの問題はバージ
ョン 4.3p2-9etch1 で修正され
ています。現時点ではサポートされているアーキテクチャの一部のみがビルド済
みで、残りは追って提供の予定です。</p>

<p>不安定版 (unstable) ディストリビューション (sid) とテスト版 (testing) デ
ィストリビューション (lenny) では、これらの問題はバージョン 4.7p1-9 で
修正されています。</p>

<p>直ぐに openssh パッケージをアップグレードし、上記の手順を行うことを勧め
ます。</p>
</define-tag>

# do not modify the following line
#include "$(ENGLISHDIR)/security/2008/dsa-1576.data"
# $Id$

© 2014-2024 Faster IT GmbH | imprint | privacy policy