これは、2020年4月に開催されたHack in the Box 2020 Lockdown Editionカンファレンスで発表した、完全なファイルシステムファジングフレームワークです。
このフレームワークの目標は、BSDシステムに重点を置いたUNIXシステム上のカーネルセキュリティバグを発見することです。FreeBSD、OpenBSD、NetBSDに対して開発され、徹底的にテストされていますが、Linuxベースのホストに対してもある程度のサポートがすでにあります。UFSおよびEXTベースのファイルシステムに対して100以上のユニークなカーネルバグを発見することに成功し、最近追加されたZFSについても多くの知見を得ることができました。
makeFS2.py は、さまざまな有効なファイルシステムを生成するためのスタンドアロンユーティリティとして使用できます。使用方法はカンファレンス資料リポジトリで詳しく説明されています。
このフレームワークはUbuntu 18.04でのみテストされています。KVM、QEMU、libvirtに依存しています。Requirements.sh が必要な依存関係をすべてセットアップします。最新のUbuntu 20.04リリースでも完全に機能する可能性があります。apt ベースではない他のホストシステムも簡単にサポート可能であり、 に小さな変更を加えるだけで済みます。必要条件が完了したら、セットアップ手順に進んでください！
Requirements.shSETUP.md を参照してください。不明な点があればお問い合わせください！
ファザーを起動するには、python3 run.py を実行するだけです。セットアップによっては、sudo 権限が必要になる場合があります。すべてが正常に起動したら、次のようにtmuxファジングセッションにアタッチできます。
(sudo) tmux attach-session -t fsfuzzer
フレームワークはスクリプト src/config/fuzzing_config.py で設定できます。
# [fuzzing task specs]
# List of dictionaries specifying each fuzzing instance
fuzzer = [
{
"name": "fuzz1", # Some name for internal bookkeeping
"fs_creator_vm": "genBox", # Name as specified in libvirt for the VM handling the file system generation, can be the same across all instances
"fuzzing_vm": "fuzzBox_0", # Name as specified in libvirt for the VM handling the file system generation
"mutation_engine": "radamsa, 0", # Mutation Engine that is to be used, and size of mutation (radamsa takes no size argument)
"target_fs": "ufs2", # Target file system
"target_size": 15, # Max file system size in Megabyte
"populate_with_files": 10, # Amount of file that will be generated
"max_file_size": 1024, # Maximum file size in bytes for each generated file
"enable_dyn_scaling": False, # Dynamic scaling will increase the filesystem size periodically
},
]
# [credentials]
# Credentials for the root user for the VMs
# It is expected that these are the same across all instances, but not necessarily root
user = "root"
pw = "root"
利用可能なミューテーションエンジンは次のとおりです。
動的スケーリングは、ファイルシステムのサイズがクラッシュの可能性に影響を与えるかどうかをテストするために当初実装されました。クラッシュが変化するファイルシステムサイズのトリガー値を特定できなかったため、このフラグは無効のままにできます。また、大きなファイルシステムはミューテーションに時間がかかるため、長時間の実行でのパフォーマンス低下を防ぐことにもなります。残りの設定パラメータは自明なはずです。
以下の動画は、2つのファジングインスタンスが両方ともFreeBSDをターゲットとし、radamsaでミューテートされたUFS2とランダムなバイトフリップされたEXTファイルシステムを使用したクイックデモです。ミューテートされたUFSファイルシステムは直接クラッシュを引き起こし、カーネルをどれだけ早くクラッシュさせられるかを示しています。
このセットアップにより、FreeBSD、NetBSD、OpenBSDのUFSおよびEXTベースのファイルシステムで100以上のユニークなカーネルバグを発見することができました。これらのクラッシュの中には、非常に興味深いものが多数含まれていました。
クラッシュの大半はカーネルDoSでした。さらに、遭遇したクラッシュの大部分は今日（2020年5月時点）でもまだ修正されていません。ファイルシステム実装におけるカーネルバグを見つけてみてください :)
この全体は「信頼駆動開発」で構築されており、単一のPoCアイデアからあまりにも早く大きくなりすぎました。そのため、テストもなく、おそらくいくつかのバグがあります。カーネルパニックとは関係ないクラッシュに遭遇した場合は申し訳ありませんが、遠慮なくPRを送るか、私に連絡してください。できるだけ早く修正します！
Twitter: @0xricksanchez