ユーザーがアップロードしたメディアファイルを処理するためにバックエンドでffmpegを使用するWebサービスに取り組んでいます。ビデオの処理方法をカスタマイズするためのオプションをユーザーに提供しています。これは、基本的にffmpegコマンドをパラメーター化しています。
Docker化された環境でffmpegを実行することを計画しています。実行ごとに新しいDockerコンテナーを使用する可能性があります。とにかく、この環境は任意のコードを実行するために使用される可能性があり、私の秘密の一部にアクセスできる可能性があります。
コマンドラインインジェクション以外に、ここで検討すべき他のセキュリティ上の問題はありますか?
編集:
私の状況に関する最新情報。ネットワークを無効にして、共有ディレクトリ経由で入力ファイルと出力ファイルを渡して、Dockerコンテナー内でffmpegを実行しています。
以下のコマンドは次のことを行います。
コマンド:
docker run -v <TEMP_DIR_ON_Host>:/temp/ --network none \
jrottenberg/ffmpeg -stats \
-i /temp/<INPUT_FILE> \
<FFMPEG_OPTIONS> \
/temp/<OUTPUT_FILE>
いくつかのメモ:
ネットワーキングを無効にして外部ファイルへのアクセスを制限することで、悪意のあるコマンドが何らかの方法で挿入された場合でも、リスクを大幅に削減できると思います。無駄なリソース以外に大きなリスクはありますか?
はい、特に任意のフォーマットを許可する場合、セキュリティ上のリスクがあります。 FFmpegは、ビデオ、オーディオ、および画像に対して、一般的な形式と不明瞭な形式の両方をサポートしています。多数のフォーマットのいずれかのデコーダーの脆弱性が悪用されて、任意のコードが実行される可能性があります。これは、FFmpegがCで記述されており、 メモリセーフ ではなく、セキュリティではなく速度が最適化されているという事実を考慮すると、さらに可能性が高くなります。 FFmpegに渡された信頼できない入力を使用して、実行中のプロセスのコンテキストで任意のコードを完全に実行し、その周囲に脅威モデルを構築できると想定する必要があります。
hardening Docker に加えて、潜在的なリスクを軽減するためにできることがいくつかあります。
Seccompサンドボックス-Dockerでseccompを有効にして、実行できるsyscallを制限します。 syscall(システムコール)は、カーネルと通信するためにユーザー空間が使用するインターフェースです。特定のシステムコールは複雑で、安全でない可能性があり、カーネルのバグを悪用する可能性があります。
形式 / コーデック-未使用のデコーダーを無効にして、デコーダーの攻撃対象領域を減らします。多くの形式、または不明瞭な機能を備えた形式には、定期的にバグがチェックされない低品質のデコーダーがあります。 Opus デコーダは許容できる品質である可能性が高いですが、 G.726 はどうですか?
リソース制限-特定のFFmpegプロセスが使用できるリソースを制限します。リソースは、システムをDoSするために使用できるだけでなく、他の脆弱性を利用して特権を昇格させる必要がある場合があります。たとえば、大きなメモリ割り当てを必要とする特定の種類の整数オーバーフローなどです。
必須アクセス制御-AppArmorやSELinuxなどのMACを使用して、アクセスを制限し、機密オブジェクトを保護します。 Dockerブレークアウト。 FFmpegがデータをアップロードまたはダウンロードする理由がないため、MACを使用してネットワーク接続を制限することもできます。
コンパイラの強化-FFmpegのビルド時に強化を使用するか、強化バージョンをダウンロードします。 PIE、SSP、およびFORTIFY_SOURCEのようなコンパイラの強化により、脆弱性が悪用されにくくなります。オペレーティングシステムがASLRを最大限に活用できるようにするため、PIEは特に重要です。