vsftp：なぜallow_writeable_chroot = YESは悪い考えですか？
Vsftpおよびallow_writeable_chroot=YESに関する数千のブログ投稿があります
一般的なエラーメッセージ：
500 OOPSの修正：vsftpd：chroot（）内の書き込み可能なルートでの実行を拒否
サーバーで問題を解決しました。
しかし、1つの質問が残っています。
allow_writeable_chroot=NOの使用が推奨されるのはなぜですか？
これまでは、「セキュリティ上の理由から」のような曖昧な議論しかありませんでした。
これらの「セキュリティ上の理由」とは何ですか？
書き込み可能なchrootを持つユーザー（仮想ユーザーも含む）のFTP資格情報が侵害された場合、攻撃者はおそらく ROARING BEAST ATTACK を実行できる可能性があります。この攻撃の大まかな理解を要約すると、一部のCライブラリ（おそらくFTPサーバーで使用されるものを含む）が、/etcまたはその他のハードコードされたパスで依存する動的ライブラリを探すという事実を悪用します一般的な場所。攻撃者はこれらの動的ライブラリの悪質なバージョンを/etcchroot内にアップロードし、それを（running-as-root）FTPサーバーに送信してそれを誘導します/etcから動的ライブラリにロードするコードを実行します。その後、攻撃者の邪悪なコードはrootとして実行されます。これにより、ユーザーのFTPフォルダーが侵害されるだけで、マシン全体がルート化される攻撃がエスカレートされます。
書き込み不可能なchrootがあると、この攻撃は不可能になります（システム管理者が、FTPユーザーのchrootディレクトリ内に/etcや/libなどの名前の書き込み可能なフォルダーを賢く作成していない場合）。
主な問題は、ドットファイルを書き込み可能にすることです。シェルに応じて、ログインのセットアップ方法、$ HOME/.sshが使用されているかどうか、他に実行されているサービス、その他いくつかのことにより、主にユーザー環境変数の操作を通じて、悪用される可能性が高くなります。攻撃が発生する前に知る必要があるため、何をどのような理由で行うかについての包括的なガイドはありません。
一言で言えば、使いやすさのために、ほとんどのディストリビューションは何らかの方法でユーザーのホームディレクトリを参照し、それを書き込み可能にすると、それらの参照が操作される可能性があります。