インフラネットワーク向けセキュリティ研究施策　SHEPHARD 第2回　ファジング技術入門

ネットワークイノベーションセンタ ネットワーク制御ソフトウェアプロジェクトの北野です。

前回(インフラネットワーク向けセキュリティ研究施策 SHEPHARD 第1回 | NIC Tech Talks)に引き続き、今回はSHEPHARDの研究施策の一つであるファジング技術について紹介したいと思います。

通信の根幹に関わる処理を実施している通信制御ソフトウェアの機能停止や取り扱い情報の漏洩は甚大な社会影響を及ぼすため、高いソフトウェア品質が求められます。
一方で通信制御ソフトウェアは高信頼性・高可用性を実現するための機能の細分化やアクセラレータへの処理移転、仮想化・コンテナ化などが進められており複雑な作りになっています。
そのため通信制御ソフトウェアにおいては、セキュリティリスクの温床となるようなバグをソフトウェアテストによってしっかり取り除くことが重要であり、単体テストや結合テスト、総合テストといった実装や仕様に基づいたテストに加えて、想定外の入力や処理実行時の情報を考慮したソフトウェアテストが重要になります。

そこで私たちが注目しているのがファジングテストです。
ファジングテストとは様々な入力を超大量に自動生成/自動実行し、仕様に基づいたテストでは洗いきれないバグや脆弱性を発見するソフトウェアテスト手法です。
図1に示すように、入力文字列の挿入/削除等をランダムに実施して入力を自動生成することで大量の入力データを送り込みながら、システムの挙動を観察することで、システムのクラッシュといった不具合を発見することが可能です。

NTTのようなインフラネットワークオペレータが通信制御ソフトウェアを社外ベンダから調達した場合、ソフトウェアのソースコードや詳細な設計情報は非公開であることが一般的です。
しかし、ファジングテストはテスト対象ソフトウェア（SUT^*1）のソースコードがなくとも、バイナリファイルのみでのテスト（バイナリファジング）が可能です。
そのため、インフラネットワークオペレータ側でファジングを実施することによって、通信制御ソフトウェアのさらなる品質向上や大規模通信障害の未然防止、お客様への安定的な通信サービスの提供につながると考えています。

ここで図2をもとに、代表的なファザーであるAFL^*2を例に処理フローを紹介したいと思います。

① テスト実施者はファザーに対してSUT^*1への入力の元ネタとなる初期テストケース（シード）を与えます
② ファザーは与えられたシードに対して変異処理を施します。変異処理には文字列の挿入や削除、ビット反転など様々な処理が含まれていて、ランダムに複数の変異を組み合わせることでファズを生成します
③ 生成したファズをSUT^*1に入力します
④ SUT^*1は受け取ったファズの処理を実行します。このとき、ファザーはあらかじめ仕込んでおいたSUT^*1の監視パッチによって、SUT^*1の処理実行時の情報（フィードバック情報）を取得します
⑤ ファザーはSUT^*1からの応答やフィードバック情報を基に、ファズに対するクラッシュの有無やSUT^*1内の新たな実行経路走行の有無等を考慮し、次のシードの生成や選択を行います

このように②～⑤を繰り返す中で、大量の入力を生成し、フィードバックを得ながら、新たな実行経路の走行につながる有力な入力を自動生成/自動実行していきます。こうして新たな実行経路の走行を目指すことで、脆弱性検出の可能性を高めていくのがAFL^*2の特徴です。
AFL^*2では、SUT^*1のソースコードが編集可能な場合はソース内に監視パッチ（計装コード）を仕込むことでフィードバック情報を得ることができます。ソースコードの編集閲覧が不可能な場合でも、SUT^*1のバイナリファイルを計装コードが仕込まれたエミュレータ上で動作させることでフィードバック情報を取得可能であり、バイナリソフトウェアに対してもファジングテストが可能となります。

インフラネットワークオペレータ側でバイナリファジングを実施する場合、大きく２つの課題があります。

近年、ファジングは学術分野でもホットトピックであり、毎年優れたファザーがOSSとして世の中に発表されています。
しかし、その分複雑性は増しており、ファザーを使いこなすためには高度なノウハウが必要になっています。
例えばSUT^*1がファザーからの入力を受け入れられるようにするためのテスト環境準備や、ファザー側から入力する初期シードの生成、フィードバック情報取得のための監視パッチの準備（計装）などが挙げられます。
これらの作業にあたってはファザー側だけでなく、テスト対象である通信制御ソフトウェアの仕様や特性を深く理解する必要があるため、テスト準備だけで月単位の時間を要することもあります。

もう一つの課題は、バイナリファジングの実行速度の遅さやテスト効率の悪さです。
バイナリファジングの実用例として、エミュレータであるQEMU上でテスト対象のバイナリを動作させ、テスト実行時のコードカバレッジ等のフィードバック情報をQEMU経由で取得する方法があります。
しかしこの方法はQEMUによる処理がボトルネックとなり、ファジングの実行速度がQEMUを用いない通常の計装と比較して数倍低下してしまうという課題があります。

課題①に対応して、私たちのチームではバイナリベースの通信制御ソフトウェアをテスト対象として、既存ファザーを使いこなすためのノウハウ蓄積に取り組んでいます。
日進月歩のファザーの中から、特に優れたファザーを見極め、通信制御ソフトウェアに適用するための手順/ノウハウ確立や、より効果的に活用するための技術確立に取り組んでいます。
2024年度には、あるOSSの通信制御ソフトウェアをテスト対象として、AFLNetというAFL^*2の派生のファザーを使って実際にファジングテストを行い、テスト実行までの手順やノウハウ、課題点などを明らかにすることができました。今後はさらに高度な機能の活用に向けて取り組みを進めていく予定です。

課題②の解決に向け、私たちのチームではバイナリファジングの効率向上に向けた研究に取り組んでいます。
効率向上に向けた研究の一つとして、フィードバック情報をより軽量に取得するための技術について研究を進めています。そのための手法として、OS等のシステムソフトウェア技術に着目しています。
OSで取得可能なシステム情報を活用してソフトウェアテスト実行時のコードカバレッジ等を推測することで、フィードバック情報の取得負荷を低減し、既存の手法に比べてバイナリファジングの実行速度を向上させることを目指しています。
他にも、バイナリファジングの効率向上に向け、ファジング実行時の不具合検出方式等の新技術の確立に取り組んでいます。

今回は通信制御ソフトウェアに対するファジングテストの重要性と、その課題及び我々の取り組みについて紹介しました。
私たちのチームの取り組みによって、通信制御ソフトウェアの品質向上を図り、お客様への安定的な通信サービスの提供に貢献していきたいと考えています。
この連載では引き続き、インフラネットワーク向けセキュリティ研究施策であるSHEPHARDの取り組みや関連技術の動向について紹介していきたいと思いますので、次回の連載もお楽しみに！

^*1SUT...Software Under Testの略。同義語としてPUT(Program Under Test)が用いられる場合もある

^*2AFL...American Fuzzy Lopの略。Google社が開発したオープンソースのファジングツール。現在でもAFLをベースとした数々の派生ファジング手法が最先端の研究成果として発表されている

(1) AFL -America Fuzzy Lop-