2005/12/18
Max Vozeler 氏は、
rssh
がインストールされている
(かつ rssh_chroot_helper が SUID インストールされている)
システムにおいて、シェルアクセスを持つユーザが root
アクセス権限を取れてしまうという問題を報告してくれた。
これは任意の場所に chroot 出来てしまうことによるものである。
この問題を緩和する要素は潜在的に沢山あるのだが、安全のためにすぐにアップグレードするべきである。
rssh
の 2.3.0 リリースでは、chroot ヘルパーにおいて、どこに chroot(2)
するかを決めるために設定ファイルを再びパースするようにし、この問題を解決している。
システムに対するシェルアクセスを持つユーザは、chroot
する場所をくつがえすことはできず、そして rssh の設定に依存した
chroot は全くできなく、それによってこの問題を解決している。
2004/12/03
Jason Wies 氏は、scp, rdist, rsync との組合わせにおいて、 rssh がどのように出し抜かれるかを報告してくれた。 この問題の原因は、これらのコマンドの、任意のコマンドの実行を引き起こすようなコマンドラインオプションにある。
rssh 2.2.3 リリースはこの問題を修正する。 exec() されるプログラムへと渡されるコマンドラインをパースし、任意のプログラムの実行を許可するようなコマンドラインオプションを含まないことを確認している。
2004/10/23
悪意のある人間が
rssh
を使うように設定されたアカウント通して任意のコードを実行できてしまうような、
文字列フォーマットバグを Florian Schilhabel が発見した。
一般的にはリスクは低く、多くの場合はそのアカウントを危険に晒すだけである。
このバグを攻撃するには、ユーザーは
ssh
でログインしていないといけないという事実が、リスクを緩和している。
すなわち、ユーザーが既知であるか、でなければ既にシステムが不正使用されていることを意味する。
しかし、setuid()
関数群の実装が腐っているような古いシステムでは、
rssh の設定によっては root の奪取も可能である。
特に、rssh が chroot jail を使用するように設定されている場合には、
chroot() を呼ぶために setuid root されていなければならない
rssh_chroot_helper
を
exec()
する。
通常、
rssh_chroot_helper
は setuid(getuid()) を呼び出し、
ロギング機能を呼び出す前に特権を落とすので、
多くのシステムでは root の奪取は困難である。
しかし、保存 UID を適切に扱わないようないくつかの古いシステムでは、
root 奪取の脆弱性がある。
Linux はこれに対しては脆弱ではなく、最近の
POSIX 互換の Unix 達もそうであるはずだ。
root 権限で呼び出された
setuid() システムコールは、すべての UID
(UID, 保存UID, 実効 UID)に指定された UID を設定すると
POSIX では定義している。
よって、一般的には、root 権限奪取は不可能であり、
可能であるようなシステムを私は具体的には知らない。
2004/05/22
訳注: 以下は作者が BUGTRAQ に投稿したメールの一部に対する翻訳であり、オリジナルのページの翻訳ではない。
rssh 2.0 〜 2.1.x には、ユーザが chroot jail 外の(意図しない)情報を得られるというバグが存在する。 rssh の最新のリリースではこの問題が修正され、また opennssh 以外の sftp クライアントに対するサポートが改善されている。 さらに、cvs・rsync・rdist を許すように拡張されている。
Mr. McCaw によって発見された問題の原因は、 rssh が chroot jail に入る前に引数を展開してしまうことにある。 このバグによってユーザが jail の外側のファイルにアクセスできてしまうことは ないが、ある jail 外のディレクトリに対して読み取り/実行権限がある場合に、そのディレクトリにどんなファイルがあるかを知られてしまう。
(William のバグ報告にある)例として、
rssh
を使った jail に制限されているサーバ上にアカウントがある場合、ユーザは次のコマンドを使うことで
/etc 以下のディレクトリにどんなファイルがあるかを知ることができる:
scp target:/etc/* .
このコマンドの結果は、以下のようになる:
scp: /etc/DIR_COLORS: No such file or directory scp: /etc/HOSTNAME: No such file or directory scp: /etc/X11: No such file or directory scp: /etc/adjtime: No such file or directory [ ... ] ld.so.cache 100% 675 0.0KB/s 00:00 ld.so.conf 100% 0 0.0KB/s 00:00 [ ... ] passwd 100% 51 0.0KB/s 00:00 [ ... ] scp: /etc/termcap-Linux: No such file or directory scp: /etc/updatedb.conf: No such file or directory scp: /etc/warnquota.conf-sample: No such file or directory scp: /etc/xml: No such file or directory
コピーに成功したファイルは chroot jail 内にあり、よってこれらは無害であるはずだ。
エラーメッセージを出しているすべてのファイルは、システムの
/etc/ディレクトリにはあるが、chroot jail
内には存在しない。
これらのファイルへのアクセスが試みられる前にユーザーは jail
内に移動されるので、もう一度言うが、それらのファイルにアクセスすることはできない。
多くのサイトにとってこれは深刻な問題ではない。
しかしながら、chroot jail
の外側にどんなファイルがあるかを知られないことが重要であるようなサイトでは、ただちにアップグレードすべきである。
rssh リリース 2.2.0 は、ここで論じた問題については修正されているが、ユーザごとのオプショを解析するコードの一部が欠けた状態で誤ってリリースされた。 リリース 2.2.1 はこの問題の修正であり、また rssh の最後のリリースになるはずだ。これ以上の開発をする計画はない。
Jul 7 2003
注意
このページはもう殆んど賞味期限切れである。
もし OpenSSH 3.5 以降と共に最新の
rssh
を使っているのなら、必要なのは
sshd_config で
PermitUserEnvironment を
no にするだけである。
そうしないならば、ユーザが rssh
の裏をかくのを許してしまうことになる。
重要なことなのだが、
rssh
に欠陥があってそうなってしまうのではないということを理解しておくこと。
詳細については、続いて以下を読んで欲しい。
Aug 22 2002
概要
ユーザーがこの問題をどのように悪用できるかの説明を含めて、この問題の詳細は後半で解説している。 現在のところ、ユーザーが rssh の裏をかいて、制限されたシステムにアクセスすることを完全に防ぐには、以下の二つの予防措置のいずれかをとらなければならない:
- rssh を静的(static)にコンパイルしてバイナリを生成する
- 制限したいユーザの environment(環境) ファイルに対し、ユーザが修正できてしまわないように努力する。
実際問題として、後者は rssh
ユーザのホームディレクトリがそのユーザに対して書き込み可であってはならず、また .ssh ディレクトリも(もしあれば)書き込み可であってはならないことを意味する。
.ssh ディレクトリを制限するだけでは十分ではない。
なぜならば、ユーザは sftp を使って .ssh
ディレクトリを削除するか、または名前を変更し、書き込み可能な新しい .ssh
ディレクトリを作成できてしまうからである。
すなわち、sftp をまるで chmod
のように使うことができるので、これはユーザが自分のホームディレクトリも所有できないという事を意味する
-- ということに注意すること。
その代わり、chattr コマンドをサポートするファイルシステム
(訳注: 訳者は ext2, ext3 以外に知りません)
を使った Linux システムでは .ssh ディレクトリに対し
chattr +i すればよい。
これらの理由により、rssh v0.9.3 において、バイナリはデフォルトでは静的にコンパイルされる。
そしてこれは動的(dynamic)にコンパイル・リンクされた
rssh
と違い、大きなバイナリ(>400k)になることに注意すること。
v1.0.0 からは、静的リンクを抑制する configure
のオプションがある。
詳細については configure --help の出力を参照のこと。
Solaris では静的にリンクされた
rssh
を動作させることは不可能なように見える。
それは、スタックやヒープ、またはその両方の上でのコードの実行を妨げるパッチを当ててないシステムであってもである。
Solaris 上で静的なバイナリを作成するのは難しい。
なぜならば、静的なライブラリの呼び出しは
dlopen() ファミリーの関数を参照するのだが、
これは私が信じられないほどの脳死状態じゃないかと思わせる。
多くの場合、それらの関数ファミリーの stub
関数を提供することで対処できるが、rssh
にこれをおこなったある人は、できたバイナリが segfault
したと報告している。
Solaris 上で
rssh
を使おうとしているなら、OpenSSH 3.5(以下を参照せよ)
にアップグレードするすることを強く推奨する。
でなければ、configure
時に手動で静的コンパイルを抑止し、かつユーザーが
rssh
の裏をかく危険を負うことになる。
詳細
この弱点は
rssh
自身にあるのではないということを、どうか気に留めておいて欲しい。
問題は、OpenSSH プロジェクトの (OpenSSH 3.5 未満のバージョンの) sshd
では、ユーザが最初に接続(ssh か scp それとも sftp であるかに関係なく)
したときに $HOME/.ssh/environment ファイルを読み込み、
ユーザがその環境で変数が設定できることを許してしまうところにある。
LD_LIBRARY_PATH や LD_PRELOAD といった
変数を設定する行を含むファイルをそこへ scp することができ、sshd
デーモンによって exec()(起動)
されるバイナリを環境変数で選択したライブラリと動的にリンクさせることをユーザに許してしまう。
これはユーザが rssh 自身に任意のコードを実行させられることを意味する。
この攻撃を防ぐためにできる唯一のことは、ユーザの環境を制御して、絶対にユーザ自身の
.ssh ディレクトリーに書き込むことができないと確信するようになることである。
OpenSSH 3.4 とそれ以前においては、ユーザ環境ファイルが読み込まれるのを防ぐ手段がない。
現在 OpenSSH 3.5 がリリースされており、これにはパーミッションの制限に頼ること無しに、この攻撃を防ぐことができるようになる
PermitUserEnvironment オプションが含まれる。
さらに、少なくともいくつかのリリースの OpenSSH の sshd(8)
man ページによれば、$HOME/.ssh/rc
ファイルに書かれているコマンドは、ユーザのデフォルトシェルではなく
/bin/sh を使って実行される。
man ページに書かれているにもかかわらず、私がテストに使えたシステムではこの事象は現れなかった。
コマンドはユーザのデフォルトシェル
(rssh)
で実行され、rc ファイルの実行を許さなかった。
しかし、もし man ページが真実であるシステムでは、悪意のあるユーザは
/bin/sh で実行される $HOME/.ssh/rc ファイルを
アップロードし、rssh の裏をかくことができてしまう。
rssh
がユーザの(ホームディレクトリの所有者とパーミッションの制限、または静的なコンパイルなしに)シェルアクセスの獲得を防いでいると確信したいならば、すでに利用可能になっている
OpenSSH 3.5 に更新することを強く推奨する。
かならず sshd の PermitUserEnvironment オプションを
no に設定すること。
日本語訳に関しての著作権・免責事項
このページおよび rssh の付属ドキュメントは原著者 Derek D. Martin 氏の許可を受けて翻訳しています。 日本語訳に関する著作権は(有)システムデザイン研究所に属します。 このページの内容は著作権法における「公表された著作物」として扱うことが可能であり、著作権法の定める範囲内において「引用」することが可能です。
本ページの内容に関して、翻訳者ならびに原著者は一切の保証を致しません。 本ページの内容に起因するいかなる損害についても翻訳者ならびに原著者は何ら責任を負いません。