UNIXおよびLinux SysAdmのマニュアル：キャッシュされたマニュアルページが「セキュリティリスク」であるのはなぜですか？

次のリスクにより、他のユーザーが使用するマニュアルページの内容（または実際にはすべてのデータ）をユーザーが操作できるようにすることは安全ではありません。キャッシュ中毒。古いBOFHジョークは次のとおりです。

システムに関するすべてを最初から学習するには、次のようにRead ManualコマンドとRead Fasterスイッチを使用します。 rm -rf /

（確かに、欲しくないこのコマンドを実行してください。 ）しかし、マンページキャッシュを制御する場合は、キャッシュされた偽のマンページを表示するために入力できます。これは、実際には「rm - ファイルまたはディレクトリの削除」の代わりに「rm - 手動読み取り」であることをman rm示しています。rmでもシェルの出力端末エスケープシーケンスにコードを挿入する。

問題のシステムがWebサーバーであるとします。また、サーバー管理者がシステムにインストールされているソフトウェアの一部をWebページを介して一般（または会社のイントラネット）に公開しているとします。イメージリサイザー、電卓、辞書と同じくらい簡単です。

ソフトウェアのインストール時に関連するマニュアルページがある場合、管理者（すばらしく思慮深い人）は、これらのマニュアルページをWebサービスユーザーに提供するのも良い考えであると判断できます。

したがって、Webページのヘルプアイコンは、1つ以上のヘルプを取得するスクリプトを実行します。キャッシュ済み- マニュアルページを作成してユーザーのブラウザに送信します。

キャッシュディレクトリへの書き込みアクセス権を持つ人またはコードは、これらのファイルを次のように変更できます。

• ユーザーのブラウザに接続して実行する任意のJavascriptを挿入します。
• すべてのアクセスユーザーからテレメトリデータを収集し、後で処理/分析するためにいくつかのリポジトリに渡します。
• 認証資格情報を収集します。システムで権限を持つユーザー（管理者など）の資格情報も収集できます。

想像力と緩い道徳/倫理を持っている人なら誰でも上記の内容をさまざまな方法で乱用することができます。

セキュリティの脆弱性は、ディレクトリが誰でも書き込み可能に設定されるたびに発生します。ディレクトリの目的が何であるか、ディレクトリを破損する方法を無視して書き込み可能にすることは問題です。

カタログ機能に関連しないいくつかの考えられる問題は次のとおりです。

• ユーザーが書き込むことができるファイルシステムに別のディレクトリがない場合、これはすべてのユーザーがそのファイルシステムで使用できないスペースを使用できるようにします。
• すべてのユーザーはこのディレクトリにファイルを保存してファイルシステムを作成し、サービス拒否攻撃を引き起こす可能性があります。 /var/logと同じファイルシステムの場合、ログに記録されないことがあります。
• ファイルは意図した場所から離れて、このディレクトリに隠すことができます。これはアカウントの削除後も続く可能性があり、ファイルシステムが奇妙にいっぱいになると見つけるのは難しいかもしれません。
• 将来キャッシュされたファイルと同じ名前のファイルまたはディレクトリを作成すると、ディレクトリが意図した目的によって正しく機能しなくなる可能性があります（ファイルの内容自体が悪意のない場合でも）。これらのファイルの権限を調整すると、自動回復がより困難になる可能性があります。

ほとんどの最新のディストリビューションは、適切なパッケージがインストールされたときの辞書キャッシュのマニュアルページ（troffを使用して処理されます）です。これは問題ではありません。

問題は、元のmanファイルが存在するがキャッシュが空の場合（つまり、キャッシュファイルが事前に作成されていない場合）に発生します。

この問題を解決する方法は2つあります。

1. troffでマニュアルページを実行する毎回ユーザーとして
2. troffを介してマニュアルページを一度実行します。根キャッシュディレクトリに保存

rootとして実行するにはsetuidが必要です。セキュリティ上の脆弱性がある場合何もないたとえば、コマンドラインの解析により、攻撃者は高い権限を取得できます。

関連ソースは次のとおりです。https://git.savannah.gnu.org/cgit/man-db.git/tree/src/man.c

幸いなことに、すべての主要なディストリビューションはマニュアルページを事前キャッシュするので、心配する必要はありません。