[論文レビュー] TCPSnitch: Dissecting the Usage of the Socket API

Gregory Vander Schueren, Quentin De Coninck+1 more|arXiv (Cornell University)|Nov 2, 2017

Advanced Malware Detection Techniques参考文献 13被引用数 3

ひとこと要約

TCPSnitch は、Android および Linux アプリケーションと TCP/IP スタック間の詳細な相互作用を傍受・ログ記録するシステムであり、システムコールパラメータ、タイムスタンプ、ソケットオプションを収集する。研究では、Facebook や YouTube といった人気アプリが、Java API に存在しないにもかかわらず、特に TCP_INFO を含む非標準的なソケットオプションを広く使用していることが明らかになった。これは、ハイレベルな抽象化と低レベルのシステム使用の間のギャップを示している。

ABSTRACT

Networked applications interact with the TCP/IP stack through the socket API. Over the years, various extensions have been added to this popular API. In this paper, we propose and implement the TCPSnitch software that tracks the interactions between Linux and Android applications and the TCP/IP stack. We collect a dataset containing the interactions produced by more than 120 different applications. Our analysis reveals that applications use a variety of API calls. On Android, many applications use various socket options even if the Java API does not expose them directly. TCPSnitch and the associated dataset are publicly available.

研究の動機と目的

• Android および Linux における実世界のネットワーク対応アプリケーションが、実際にソケット API をどのように使用しているかを理解すること。
• ハイレベルなプログラミング抽象化（例：Java API）と低レベルのシステムコールとの間に生じる不一致を特定すること。
• 研究用に大規模かつパrameter豊富なソケットシステムコールトレースデータセットを収集・公開すること。
• 非標準的なソケットオプション（例：TCP_INFO を含む）の実際の使用パターンを分析すること。
• 実アプリケーションのニーズを明らかにすることで、将来の汎用トランスポートサービスの設計を支援すること。

提案手法

• TCPSnitch は LD_PRELOAD を使用して、C ライブラリ内のネットワーキング関連の 40 項のキーファンクション（socket、connect、send、recv、getsockopt など）を傍受する。
• タイムスタンプ、関数パラメータ、戻り値、スレッド ID、システム構成などの詳細なメタデータをログ記録する。
• トレースは https://tcpsnitch.org に公開されたデータベースにアップロードされ、ビジュアライゼーションとクエリインターフェースが提供される。
• 本システムは 90 個の人気 Android アプリおよび Linux システムに展開され、230 万件を超えるシステムコールが収集された。
• データセットにはソケットオプション、バッファサイズ、フラグの使用状況が含まれており、API の挙動を細かく分析可能である。
• ウェブインターフェースにより、研究者はトレースをブラウズでき、アプリケーションやソケットオプションでフィルタリングし、使用パターンを探索できる。

実験結果

リサーチクエスチョン

• RQ1 実世界の Android および Linux アプリケーションは、実際にシステムコールのシーケンスやパラメータの観点から、ソケット API をどのように使用しているのか？
• RQ2 Android において、Java API に露出されていない非標準的なソケットオプション（特にそのようなもの）は、どの程度使用されているのか？
• RQ3 接続確立および終了のプロセスにおいて、SO_LINGER や SO_DEBUG の使用に関するどのようなパターンが顕在化するのか？
• RQ4 TCP_INFO などの高度なソケットオプションはどの程度頻繁に使用されており、アプリケーションや接続ライフタイムに応じてその分布はどのようになっているのか？
• RQ5 Android アプリケーションにおける UDP ソケットの実際の使用状況は何か？これはその意図された用途と比べてどう異なるのか？

主な発見

• IPv6 対応の WiFi ネットワークでは、Android アプリケーションが IPv4 よりも IPv6 を優先し、78% の接続が IPv6 を使用している。
• UDP ソケットは、実際のデータ転送のためではなく、主にネットワーク構成のプローブを軽量な手段として使用している。
• TCP 接続ライフサイクルにおいて一貫したパターンが確認された：アプリケーションは close() の前に getsockopt(SO_LINGER) および getsockopt(SO_DEBUG) を実行し、ソケット固有のクリーンアップ処理を検出・処理している。
• 28 個の Android アプリケーションが非標準の TCP_INFO ソケットオプションを使用しており、これは内部 TCP スタックのカウンタを暴露するものである。26% の TCP_STREAM ソケットが少なくとも1回はそれを取得している。
• Facebook、Messenger、Instagram では、1接続あたり最大 3,000 回もの TCP_INFO 呼び出しが行われており、開始時や終了時だけではなく、時間軸全体にわたって均等に分布している。
• Java API に露出されておらず非標準であるにもかかわらず、YouTube や Chrome、Spotify といった高トラフィックアプリケーションが TCP_INFO を使用している。これは、ハイレベルな抽象化と低レベルのシステムアクセスの間に顕著なギャップが存在することを示している。