BusyBoxソフトウェアの脆弱性に対処する
IoTデバイスで使われてるBusyBoxのセキュリティを強化するための技術を調査中。
― 1 分で読む
目次
BusyBoxは、300以上の基本的なLinuxコマンドを1つの実行ファイルにまとめた人気のソフトウェアツールだよ。特にリソースが限られたIoTデバイスでよく使われてる。だから、BusyBoxの脆弱性を見つけて修正するのはとても重要なんだ。
BusyBoxの脆弱性は深刻なセキュリティ問題につながる可能性がある。例えば、リモートコード実行の脆弱性があると、攻撃者がデバイスを乗っ取ることができちゃう。不運なことに、多くのデバイスは既知の脆弱性を持つ古いバージョンのBusyBoxを使ってる。これは、ルーターやカメラ、その他のネットワーク機器にとって大きなセキュリティ上の懸念を引き起こすよ。
バグ検出の必要性
IoTデバイスの数は急速に増えていて、それに伴いセキュリティの脅威も増加してる。ファームウェアはデバイスを制御するソフトウェアで、いくつかのコンポーネントで構成されてるんだ。その中にはBusyBoxのようなサードパーティのソフトウェアパッケージも含まれてる。1つの部分に欠陥があると、多くのデバイスに影響を与えるから、これらのコンポーネントを常にチェックするのが重要なんだ。
ファームウェアにはさまざまな種類がある。例えば、標準のオペレーティングシステムで動くものもあれば、リアルタイムオペレーティングシステムで動くものや、全くオペレーティングシステムがないものもある。これらの中で、Linuxベースのファームウェアが最も一般的だね。このタイプのファームウェアはBusyBoxのようなアプリケーションソフトウェアをよく使うから、攻撃の可能性が多くなる。
ファズテストの重要性
ファズテストはソフトウェアの脆弱性を特定するための技術だよ。ランダムなデータや予期しないデータをプログラムに入力して、クラッシュや異常な動作を探すんだ。プログラムがクラッシュすると、脆弱性があるかもしれないってサインになることがある。
この研究では、BusyBoxのファズテストを改善することに焦点を当てたんだ。脆弱性をより効果的に見つけるための2つの主な技術を開発したよ。
LLM)を使ったシード生成
大規模言語モデル(最初の技術は、ファズテストの初期入力シードを生成するために大規模言語モデル(LLM)を使うことだよ。これらのモデルはコードのパターンに基づいて高品質なデータを生成できるから、テスト結果が良くなるんだ。
実験では、LLM生成のシードを使ったときに、ファズテスト中のクラッシュ検出数が大幅に増加することがわかった。これは、LLMがソフトウェアに問題を引き起こす可能性のある入力を見つけるのにとても役立つことを示してる。
言語モデルを活用することで、初期シードの作成プロセスを自動化できて、時間を節約しテストプロセスの効果を高められるよ。このアプローチの前は、質の高い入力データを生成するのに時間がかかり、テスターには手間のかかる作業だったんだ。
クラッシュデータの再利用
2つ目の技術は、古いバージョンのBusyBoxからクラッシュデータを取り出して、新しいバージョンに適用することだよ。このアプローチは、以前に検出された脆弱性が更新されたソフトウェアに今も存在するかを特定する手助けになる。クラッシュデータを再利用することで、新しいバージョンのプログラムが似たような問題を抱えているかどうかを、ファズテストをゼロから始めずにすぐに評価できるんだ。
この技術はテストプロセスを非常に効率的にするよ。新しいバージョンのテストに何時間もかける代わりに、既知の問題のコレクションから始めて、それが新しいソフトウェアで問題を引き起こすかを見ることができる。これは、時間に制約のある製品に特に役立つ。
サイバーセキュリティの懸念
接続されたデバイスの増加は、サイバーセキュリティの懸念を高めてる。カメラやスマートサーモスタット、ルーターのような埋め込みデバイスは、ソフトウェアの弱点を突こうとする攻撃者の標的になりやすいんだ。
古いバージョンのソフトウェアコンポーネント、つまりBusyBoxの旧バージョンは多くの製品に見られる。私たちの研究では、まだ使われている古いBusyBoxのバージョンが幅広く存在し、たくさんの既知の脆弱性を含んでいることが明らかになった。これによって、セキュリティを確保するためにシステムを更新することの重要性が強調されたよ。
研究の質問
プロジェクト中に、次の質問に答えようとしたよ:
- 古いバージョンのBusyBoxはどれくらい広まっていて、これらのバージョンの脆弱性を迅速に見つけるにはどうすればいいのか?
- LLMの力をどうやって埋め込みソフトウェアのファズテストを改善するのに活用できるのか?
ファズテストとそのバリエーション
ファズテストにはいくつかの形式がある。ブラックボックスファズングでは、テスターはソフトウェアの内部動作を知らない。対して、ホワイトボックスファズングではプログラムのコードに完全にアクセスでき、汚染分析のような手法を使ってより徹底的にアプローチできるよ。
グレー ボックスファズングはその中間にあたる。プログラムの内部状態に関する部分的な知識を使い、両方のアプローチの要素を組み合わせている。私たちのプロジェクトでは、AFL++というツールを使って主にグレー ボックスファズングを利用した。これは、入力が実行中のコードにどう影響するかを追跡するように設計されてるんだ。
研究の目的
私たちの主な目標は、ファズテストにおけるLLMの可能性を示すことと、古いバージョンのBusyBoxからのクラッシュデータを効率的に使って新しいバージョンを評価することだったよ。
提案した技術を使ってさまざまなBusyBoxコンポーネントのファズテストを実施することで、脆弱性を特定し、これらのコンポーネントがどのように悪用される可能性があるかをよりよく理解することを目指したんだ。
実験の準備
テストは、実際の埋め込み製品からBusyBoxのバイナリを調達するところから始めた。このバイナリは、さまざまなソフトウェアサンプルを含む独自のデータセットを使用して収集されたんだ。
テスト自体は2つの主要なステージで行われた:
- 初期シード生成にLLMを使用:強力なLLMであるGPT-4を使って、ファズテストのためのシードを生成したよ。
- クラッシュ再利用技術の適用:古いバージョンのBusyBoxからのクラッシュデータを活用して最新バージョンをテストし、脆弱性を探ったんだ。
結果
LLMを使ったシード生成
私たちのテストでは、ランダムシードと比較してLLM生成のシードを使用したときに検出されたクラッシュの数が明らかに増加した。これは、LLMがファズテストにとってより関連性が高く、効果的な入力を提供できることを示してる。
結果は、単により良い初期入力を使うことでファズテストの結果を大幅に改善でき、ソフトウェアの挙動を深く調査するきっかけになることを示してる。
クラッシュ再利用技術
最新のBusyBoxバージョンに私たちのクラッシュ再利用技術を適用することで、広範なファズテストを実施せずに多くのクラッシュを特定できたよ。古いバージョンから集めた多くのクラッシュの中で、最新バージョンで問題を引き起こしたものがかなりあった。
この発見は、新しいソフトウェアバージョンで脆弱性を迅速に発見するためにクラッシュ再利用が非常に効果的で、リソースを少なくできることを強調してる。
手動クラッシュ分析
テストを終えた後、発見したクラッシュの手動分析を行った。このプロセスでは、クラッシュを分類し、その根本原因を特定したんだ。GDBのようなツールでデバッグしたり、Ghidraでリバースエンジニアリングしたりしたよ。
分析中、いくつかのクラッシュがBusyBoxが依存するGLIBCライブラリ内の問題に関連していることがわかった。これらの問題は以前に報告された脆弱性に似ていて、ソフトウェアが更新されてもこうしたバグが持続することを示してる。
調査結果の広範な影響
私たちの研究は、BusyBoxの具体的な脆弱性を明らかにしただけでなく、埋め込みソフトウェアコンポーネントの継続的な監視の必要性も強調してる。古いソフトウェアバージョンの存在は、デバイスのセキュリティを損なうリスクをもたらすんだ。
提案された技術を実施することで、開発者やセキュリティ専門家は脆弱性をより効率的に検出でき、全体的なサイバーセキュリティを強化できるよ。
今後の研究
この研究は、さらなる探求の新しい領域を開いている。LLMやクラッシュ再利用技術を他のソフトウェアコンポーネント、特に埋め込みシステムにおけるテストで適用する可能性がたくさんあるんだ。
将来の研究では、異なるプロトコルのユニークな入力フォーマットに特化してトレーニングされたLLMを作成することに焦点を当てることができるかもしれない。これによって、あまり一般的でない標準を使用するデバイスでのファズテストの効果が大いに高まるだろう。
さらに、クラッシュ再利用技術は、さまざまなソフトウェアコンポーネントに適応できるようにして、さまざまなプラットフォームやデバイスでより堅牢なセキュリティ評価を行えるようになるよ。
結論
BusyBoxに関する調査は、ソフトウェアテストの方法論を改善する大きな可能性を示したよ。初期入力シードを生成するためにLLMを活用し、古いバージョンのクラッシュデータを再利用することで、古いソフトウェアを実行する多くのデバイスの脆弱性を効果的に特定できるんだ。
サイバーセキュリティへの懸念が高まる中、埋め込みデバイスのテストと保護の方法を継続的に改善する必要があることが強調されてる。私たちの成果は、古いソフトウェアコンポーネントによって引き起こされるセキュリティの課題に対処するためのより大きな認識と行動を促すものだよ。
要するに、この研究はファズテストにおける新しい技術の効果と、悪用を防ぐためにソフトウェアを最新の状態に保つことの重要性を強調しているんだ。
タイトル: Fuzzing BusyBox: Leveraging LLM and Crash Reuse for Embedded Bug Unearthing
概要: BusyBox, an open-source software bundling over 300 essential Linux commands into a single executable, is ubiquitous in Linux-based embedded devices. Vulnerabilities in BusyBox can have far-reaching consequences, affecting a wide array of devices. This research, driven by the extensive use of BusyBox, delved into its analysis. The study revealed the prevalence of older BusyBox versions in real-world embedded products, prompting us to conduct fuzz testing on BusyBox. Fuzzing, a pivotal software testing method, aims to induce crashes that are subsequently scrutinized to uncover vulnerabilities. Within this study, we introduce two techniques to fortify software testing. The first technique enhances fuzzing by leveraging Large Language Models (LLM) to generate target-specific initial seeds. Our study showed a substantial increase in crashes when using LLM-generated initial seeds, highlighting the potential of LLM to efficiently tackle the typically labor-intensive task of generating target-specific initial seeds. The second technique involves repurposing previously acquired crash data from similar fuzzed targets before initiating fuzzing on a new target. This approach streamlines the time-consuming fuzz testing process by providing crash data directly to the new target before commencing fuzzing. We successfully identified crashes in the latest BusyBox target without conducting traditional fuzzing, emphasizing the effectiveness of LLM and crash reuse techniques in enhancing software testing and improving vulnerability detection in embedded systems. Additionally, manual triaging was performed to identify the nature of crashes in the latest BusyBox.
著者: Asmita, Yaroslav Oliinyk, Michael Scott, Ryan Tsang, Chongzhou Fang, Houman Homayoun
最終更新: 2024-03-06 00:00:00
言語: English
ソースURL: https://arxiv.org/abs/2403.03897
ソースPDF: https://arxiv.org/pdf/2403.03897
ライセンス: https://creativecommons.org/licenses/by/4.0/
変更点: この要約はAIの助けを借りて作成されており、不正確な場合があります。正確な情報については、ここにリンクされている元のソース文書を参照してください。
オープンアクセスの相互運用性を利用させていただいた arxiv に感謝します。
参照リンク
- https://www.ndss-symposium.org/wp-content/uploads/2017/09/towards-automated-dynamic-analysis-linux-based-embedded-firmware.pdf
- https://gtfobins.github.io/
- https://jfrog.com/blog/unboxing-BusyBox-14-new-vulnerabilities-uncovered-by-claroty-and-jfrog/
- https://github.com/asmitaj08/FuzzingBusyBox_LLM
- https://pages.cs.wisc.edu/~remzi/OSTEP/
- https://www.usenix.org/legacy/event/osdi02/tech/waldspurger/waldspurger.pdf
- https://github.com/rchtsang/ffxe
- https://anonymous.4open.science/r/ffxe-anon