【ITニュース解説】firmware-auditor: Zero-Emulation Static Security Analysis for Firmware Rootfs in CI/CD

IoTデバイスや組み込みLinuxシステムといった、私たちの身の回りにある多くの機器がソフトウェアによって動いている。これらのシステムを開発する上で、セキュリティは非常に重要な要素だが、そのセキュリティを評価する作業はこれまで多くの課題を抱えていた。主に、手作業による地道な検査か、QEMU（キューエミュ）のようなエミュレータを使ってソフトウェアを仮想的に実行する「動的解析」という二つの方法が取られてきた。動的解析は実際に脆弱性を確認する上で非常に価値のある手法だが、開発の自動化が進むCI/CD（継続的インテグレーション／継続的デリバリー）パイプラインに組み込もうとすると、いくつかの問題に直面することが多かった。

動的解析には、まず実行にかかる時間と計算資源が膨大になるという課題があった。例えば、CI/CDパイプラインは開発者がコードを変更するたびに自動でテストを実行し、フィードバックを素早く返すことを目指しているが、動的解析は時間がかかりすぎるため、このスピード感を損ねてしまう。また、IoTデバイスや組み込みシステムは、それぞれに特有のハードウェア（カスタムの不揮発性メモリ、ベンダー独自の周辺機器、特殊なシステム・オン・チップなど）を持っていることが多い。一般的なエミュレータでは、これらの特殊なハードウェアを完全に再現することが難しく、正確なエミュレーションができないために解析がうまく機能しないケースが頻発する。これにより、CI/CDパイプラインの自動化が不安定になり、開発者の生産性を低下させてしまうという状況があった。

このような課題を解決するために開発されたのが「firmware-auditor」という新しいツールだ。これは、ファームウェアのルートファイルシステム（システムの基本的なファイルやディレクトリが集まった部分）が展開された状態であれば、ターゲットのバイナリを実際に実行することなく、高速にセキュリティ解析を行う「ゼロエミュレーションの静的解析フレームワーク」である。つまり、仮想的な実行環境を用意する必要がなく、ファイルの内容を検査するだけでセキュリティ上の問題点を発見できるのが特徴だ。

firmware-auditorの基本的なアイデアは非常にシンプルで強力だ。ファームウェアに含まれるSquashFS、ext4、UBIFSといった形式のルートファイルシステムが展開されていれば、そこに隠された多くのセキュリティ上の兆候を、実際にシステムを起動させずに、オフラインで確認できるということだ。具体的には、主に二つの観点から解析を行う。

一つ目は、「ELFバイナリの強化状況」だ。ELF（Executable and Linkable Format）は、LinuxなどのUNIX系システムで実行可能なプログラムや共有ライブラリの標準的なファイル形式である。firmware-auditorは、これらのバイナリが最新のセキュリティ対策（「hardening」と呼ばれる強化策）が施されているかを確認する。例えば、NX（No eXecute）/DEP（Data Execution Prevention）という技術で、データ領域でのコード実行を防ぐ対策が取られているか。ASLR（Address Space Layout Randomization）/PIE（Position Independent Executable）という技術で、メモリ上の配置をランダム化し、攻撃者が予測しにくくしているか。スタックカナリアという技術で、スタックオーバーフロー攻撃を防ぐ仕組みが組み込まれているか。そして、RELRO（Relocation Read-Only）という技術で、プログラムのロード時に重要なメモリ領域が書き換えられないように保護されているか、といった点を詳細にチェックする。これらの対策が不足しているバイナリは、古典的な攻撃手法に対して脆弱である可能性がある。

二つ目は、「ファイルシステムの衛生状態と機密情報の露出」だ。これは、開発プロセスで意図せずプライベートなSSHキー（安全なリモート接続に必要な秘密鍵）、世界中の誰でも読み取り可能な/etc/shadowファイル（ユーザーのパスワードハッシュが保存されている極めて重要なファイル）、あるいは誰でも書き込み可能なスクリプトなどが、本番環境のファームウェアイメージに組み込まれてしまっていないかを確認する。これらの情報が露出していると、デバイスへの不正アクセスや情報漏洩に直結する深刻な脆弱性となる。firmware-auditorは、これらの問題点を具体的に指摘し、開発パイプラインが致命的な問題で停止するように（DevSecOpsゲートとして機能するように）、標準化された機械可読な結果を出力できる。

例えば、意図的に脆弱性を埋め込んだテスト用のルートファイルシステムをfirmware-auditorで解析した結果では、実行時間がわずか0.007秒と非常に高速で、binary_hardeningとfilesystem_hygieneという二つのアナライザが実行されたことが示されている。このテストでは、CRITICAL（致命的）な脆弱性が5件検出された。具体的には、「世界書き込み可能なディレクトリ」があること、ファームウェアイメージ内に「プライベートキーファイル（etc/id_rsa）」が含まれていること、「機密性の高いファイル（etc/id_rsa; shadow）が世界書き込み可能」であること、そして「パスワードハッシュデータベース（etc/shadow）が任意のユーザーによって読み取り可能」であること、といった問題が挙げられた。これらは実際にデバイスの乗っ取りや情報漏洩につながりかねない、非常に危険な設定ミスや情報の露出である。

firmware-auditorはPython 3.10以降で開発されており、非常にモジュール化された設計が特徴だ。これは、各解析機能（アナライザ）が独立しており、それぞれが「フォールトアイソレーション（障害隔離）」の境界内で実行されることを意味する。つまり、たとえ一つのアナライザにバグがあったり、解析対象のバイナリが破損していたりしても、その問題が原因で全体の解析が停止してしまうことがないようになっている。各アナライザにはタイムアウトガードも設定されており、無限ループに陥ることも防いでいる。このように堅牢な設計により、再現性と信頼性の高い解析が可能になっている。

現代の開発では、CI/CDパイプラインにセキュリティ検査を組み込むことがDevSecOps（開発、セキュリティ、運用を統合するアプローチ）の重要な要素となっている。firmware-auditorは、解析結果をSARIF v2.1.0という標準形式で出力する機能を持っている。SARIFは、セキュリティ解析結果を記述するための国際標準であり、GitHub Code Scanningなどの多くのセキュリティツールやプラットフォームでサポートされている。これにより、firmware-auditorで検出された脆弱性は、GitHubのリポジトリの「Security > Code scanning」タブに直接表示されるようになる。開発者は、プルリクエスト（コード変更の提案）が行われた際に、自動的にセキュリティ上の問題がチェックされ、その結果をGitHubのインターフェース上で確認できるため、手軽にセキュリティ品質を向上させることができる。--fail-on highのようなオプションを使うと、深刻度の高い問題が見つかった場合にCI/CDパイプラインのビルドを失敗させることも可能であり、セキュリティ上のリスクが本番環境に混入するのを未然に防ぐ強力なゲートウェイとして機能する。

firmware-auditorは非常に有用なツールだが、静的解析の性質上、いくつかの限界があることも理解しておく必要がある。まず、これは「動的解析の完全な代替」ではない。実際にコードがどのように実行されるか、特定の入力に対してどのような振る舞いをするかといった「ランタイムの脆弱性」や「ロジックの脆弱性」を発見することはできない。エクスプロイト（脆弱性を悪用する行為）が可能であるかどうかの確認も、動的解析の領分だ。また、バンドルされているライブラリのバージョンと既知の脆弱性（CVE）とのマッチング機能は、現在のところ搭載されていない。スタックカナリアの検出についても、最適化によってシンボル情報が削除されたバイナリ（ストリップされたバイナリ）や静的にリンクされたバイナリでは、正確な検出が難しい場合がある。さらに、firmware-auditorは「既に展開されたルートファイルシステム」を必要とするため、ファームウェアイメージが暗号化されていたり、独自のプロプライエタリなコンテナ形式で提供されていたりする場合には、別途、事前にイメージを展開する手順が必要となる。そして、ファイルシステムのパーミッションチェックは、unsquashfsやtar、Linux環境など、Unixのパーミッションモードを正確に保持してファイルを展開するツールや環境で行われる必要がある。WindowsのNTFSなどにコピーすると、この情報が失われてしまうため、信頼できる結果が得られない可能性がある点にも注意が必要だ。

firmware-auditorはMITライセンスのもとでオープンソースとして公開されており、誰でも自由に利用、改良、配布できる。プロジェクトのソースコードはGitHubで入手可能であり、テストスイートはLinuxとWindowsの両方でCI上で実行されることが確認されている。組み込みデバイスの開発者、IoTセキュリティの専門家、DevSecOpsの推進者など、この分野に関わるすべての人々が、自身のファームウェアイメージで試用し、新しい解析ルールモジュールの開発や、バグ報告、機能改善の提案などを通じてプロジェクトに貢献することが期待されている。このようなコミュニティの力によって、firmware-auditorはさらに進化し、より多くのデバイスのセキュリティ向上に貢献していくことだろう。