【ITニュース解説】My universal document converter guessed 'text/plain' for a virus and returned the source code

あるエンジニアが、様々な形式のドキュメントをまとめて処理できる便利なツールを作った話がある。このツールは、PDFやWordファイル、Excelシート、プレゼンテーション資料、電子書籍、HTMLファイル、そして普通のテキストファイルなど、いろいろな種類のドキュメントを、一つのウェブ上の窓口（これを「エンドポイント」と呼ぶ）に送るだけで、特定の形式に変換してくれるものだった。特に、それぞれのファイルの「中身の目印」であるマジックバイトを読み取って、それがどんな種類のファイルなのかを自動で判断し、適切な変換方法を選んでくれるのが特徴だった。例えば、PDFならPDF用の変換機へ、WordファイルならWord用の変換機へ、といった具合だ。これにより、使う側はファイルの種類を意識することなく、どのファイルでも同じように扱える、非常にスマートで効率的なシステムが実現された。

このシステムは順調に動き出していた。例えば、JavaScriptのコードが書かれたファイルが送られてきた場合、マジックバイトを読み取る機能がそれを「アスキー文字の集まり」だと判断し、「text/plain」（ただのテキストファイル）として処理した。そして、そのコードを整形されたMarkdown形式に変換して返した。これは意図通りの動作だった。また、HTMLファイルの中に、別のデータを暗号のようにエンコード（base64という形式）した部分が含まれていても、HTMLファイルとして正しく処理され、何も問題はなかった。

しかし、ある時、予期せぬ事態が起こった。それは、プログラムを実行するためのファイル、つまり「.exe」ファイルがシステムに入力された時だった。この「.exe」ファイルはWindowsの実行ファイルによく見られる「MZ」という特定の文字列で始まっていたが、この時点では「.exe」ファイルを専門的に解析する機能がまだシステムに組み込まれていなかった。そのため、システムはこれを「認識できないファイル」と判断し、最終的に「text/plain」として扱うという「フォールバック」（代替処理）に回してしまった。

ここからが問題だった。本来バイナリデータである「.exe」ファイルを、システムはテキストファイルとして扱おうとし、文字コードの一種であるUTF-8形式でデコード（解読）しようと試みた。しかし、バイナリデータは文字データではないため、正しくデコードできるはずがない。結果として、デコードできない部分の文字は、Unicodeの「U+FFFD」という「文字として認識できません」という意味の記号（よく「���」と表示される）に置き換えられてしまった。最終的に、340KBもの膨大な「���」がずらりと並んだMarkdown形式のコードブロックが返され、システムはこれを「置き換え文字に関するドキュメント」として要約してしまうという珍妙な結果になった。

この経験から、開発者は重要な教訓を得た。それは、「フォールバック」として設定された処理、つまり「もしこれがダメならこうする」という代替の処理が、実は予期せぬ「セキュリティ上の弱点」になり得るということだ。ファイルを自動で判別する際に、「これは許可する」という明確なリスト（「許可リスト」または「ホワイトリスト」と呼ぶ）を用意せず、何でもかんでも受け入れてしまう設定にしていると、解析できないファイルはすべて「テキスト」として扱われる危険性がある。

もし、この「テキスト」として扱われたデータが、近年注目されている大規模言語モデル（LLM）のような人工知能の入力としてそのまま使われた場合、深刻な問題が起こる可能性がある。例えば、悪意のある「.exe」ファイルがテキストとして誤認識され、それがLLMに渡されると、その中身が悪意のある命令として解釈され、「プロンプトインジェクション」という攻撃につながるかもしれない。これは、LLMに本来意図しない動作をさせるために、悪質な指示を紛れ込ませる手法だ。また、バイナリファイルのごみデータがLLMの学習データ（「エンベディング」と呼ばれる、モデルがデータを理解するために使う数値表現）に混じってしまうと、LLMの性能が低下したり、予期せぬ振る舞いをしたりする原因にもなる。

この問題を解決するために行われた修正は、単純だが非常に効果的だった。まず、マジックバイトを正確に読み取り、それが「サポートされているファイルタイプ」の明確な「許可リスト」に含まれているかを厳密にチェックするように変更した。そして、許可リストに含まれないファイル、例えば「.exe」やMacのディスクイメージファイル（.dmg）、圧縮ファイル（.zip）など、あるいは最初の512バイトの中に「ヌルバイト」という安全ではない可能性のあるデータが含まれているファイルなど、サポート対象外のファイルが来た場合には、明確に「415 Unsupported Media Type」（サポートされていないメディアタイプです）というエラーコードを返すようにした。

この変更により、元々「ユニバーサル（汎用的な）」だったエンドポイントは、引き続き「ドキュメント」に対しては汎用的に機能するものの、「あらゆる種類のファイル」に対しては汎用的ではなくなった。これは、セキュリティを確保するための重要な判断だった。

この出来事が示すように、エージェントなどのシステムがドキュメントを取り込む際の「ファイルタイプ検出」機能は、単なる便利な機能ではない。それは、システムを守るための「最初の防衛線」となる非常に重要な役割を担っている。システムに未知のものが入力された場合、それが安全であると明確に証明されるまでは、「敵対的」なものとして扱うべきだというセキュリティの基本原則を改めて教えてくれる事例である。