🍯 👍 🗡️ PVS-Studioを使用したWiresharkの静的分析 🔠 😋 📪

この記事では、例としてオープンソースのWiresharkプロジェクトを使用して、C / C ++のプログラムコードの静的分析にPVS-Studioを使用する方法を説明します。まず、WiresharkネットワークトラフィックアナライザーとPVS-Studio製品の簡単な説明から始めます。アセンブリプロセスの落とし穴と静的解析のためのプロジェクトの準備について説明します。 PVS-Studio製品の全体像、その利点、使いやすさを図り、アナライザーの警告、コード例、独自のコメントを提供します。

Wiresharkネットワークトラフィックアナライザー

PVS-Studioの機能を実証するには、よく知られていて便利で興味深いオープンソースプロジェクトを見つける必要がありましたが、その分析はまだ誰も行っていませんでした。 Wiresharkに落ち着きました。彼は彼に無関心ではありません。あなたが彼についてまだ知らないなら、おそらくこの記事を読んだ後、彼に対する私の気持ちを共有してください。

インターネットの急速な発展とハッカープログラマーに関する多数の映画は、長い間コンピューターネットワークに注目を集めてきました。そして今、私は、セキュリティを気にする資格のあるシステム管理者とプログラマは、ネットワーク技術を理解する必要があるように思えます。

ネットワークは、特定のプロトコルによるデータの受信と送信に基づいています。ネットワークアプリケーションとプロトコルの研究を行い、ネットワークの問題を見つけ、重要なことにはこれらの問題の原因を見つけるために、ネットワークトラフィックまたはスニファーをキャプチャおよび分析するためのツールを使用する必要があります。

Wiresharkは、グラフィカルユーザーインターフェイスを使用してネットワークトラフィックをキャプチャおよび分析するための有名なツールです。このプログラムは、Pcapネットワークトラフィックをキャプチャするためのライブラリに基づいており、既知のネットワークプロトコルパケットの大半を解析して、あらゆるレベルの各プロトコルフィールドの値を表示できます。

Wiresharkは、WindowsおよびLinuxで実行するように設計された無料のGNU GPLの下で配布されるクロスプラットフォームツールです。グラフィカルインターフェイスを作成するには、GTK +およびQtライブラリを使用します。

プログラムのドキュメントとソースコードは、 Webサイトにあります。

PVS-Studio Static Code Analyzer

静的コード分析により、アプリケーションを実行せずに、作業環境に関係なくソフトウェアのエラーを見つけることができます。静的分析を使用すると、ソフトウェア製品の品質を向上させ、開発とテストの時間を短縮し、セキュリティを確保できます。

PVS-Studioは、MS Visual C ++、GNU GCC（MinGW）、Clang、Borland C ++コンパイラをサポートする静的C / C ++ / C ++ 11コードアナライザーです。

PVS-Studioには次の診断が含まれています。

汎用診断;
64ビットエラーの診断。
可能な最適化の診断。

PVS-Studioに関する追加情報は、 Webサイトで見つけることができます。

Wiresharkプロジェクトの構築

静的分析を行うには、Wireshark 1.12.4の最新の安定バージョンのソースをダウンロードします。 Visual Studio 2013に含まれるコンパイラを使用して、Win64プラットフォーム用のWindows 7オペレーティングシステムにビルドします。さらに、Qt SDK 5.4.1およびWinPcap 4.1.3ライブラリをインストールします。

nmakeを使用してコマンドラインからビルドします。アセンブリスクリプトを正しく機能させるには、CygwinおよびPython 2.7.9をインストールします。

アセンブリに関する追加情報は、 Webサイトで見つけることができます。

アセンブリは指示に従って完全に実行されたという事実にもかかわらず、多くのエラーが発生しました。それらを排除するには、それが必要でした：

PATH環境変数にCygwinへのパスを記述して、コンソールからbashシェルにアクセスできるようにします。
CygwinでNTFSのアクセス制御ACLを無効にして、所有者にファイルの書き込み、読み取り、実行の権限を付与します。
オプションのdos2unixパッケージをCygwinにインストールします。なぜならコンパイルにはu2dユーティリティが必要でした。
nmakeのcleanコマンドが機能するように、Makefile.nmakeファイルを「asn1 \ hnbap」から「asn1 \ kerberos」にコピーする必要がありました。

PVS-Studioを使用した静的解析

ライセンス付きでPVS-Studio 5.25をインストールしましたが、プログラムを初めて使用する場合は、デモバージョンをダウンロードしてインストールできます。

トライアルモードでは、警告は最初のレベルでのみ使用できます。インストール後のコードのジャンプは50回まで、自分に関する情報の送信後の移行は50回までです。 100の移行後、ライセンスが必要になります。ライセンスの購入条件は、サイトで確認できます。もちろん、これらの100個のトランジションは使用するのに十分ではなく、プログラムの最初の知り合いに提供されます。アナライザーをより詳しく知りたい場合は、サポートに書き込み、数日間登録キーを取得できます。

Wiresharkプロジェクトはコマンドラインからnmakeを使用して構築されているため、PVS-Studioに含まれる監視システムが必要です。コンパイラの起動を監視し、環境に関する情報を収集します：作業ディレクトリ、コマンドライン、コンパイルされたファイルへのフルパス、プロセス環境変数。

監視するには、「スタート\ PVS-Studio \ PVS-Studioスタンドアロン」を実行し、メニュー項目「ツール\ファイルの分析...」を選択し、「監視開始」ボタンをクリックします。次に、コマンドラインから、上記のようにプロジェクト「nmake -f Makefile.nmake all」のアセンブリを実行します。「監視の停止」ボタンをクリックして、アセンブリが成功したことを確認し、監視を完了します。

我慢しますその後、静的解析が自動的に開始されます。完了後、アセンブリおよび静的解析を数回実行しないように、レポートplogファイルを保存します。

PVS-Studio Standaloneプログラムのこの段階ですでに、エラーの検索を開始できます。ただし、IntelliSenseコードの高度なナビゲーション機能を使用するには、Microsoft Visual Studioでレポートを開くことをお勧めします。

これを行うには、一連のアクションを実行します。

Wiresharkソースフォルダーに空のVisual C ++プロジェクトを作成します。
ソリューションエクスプローラーで、ファイル表示モードに移動します。
プロジェクトにソースを追加します。
プラグイン「PVS-Studio \ Open Analysis Report」を使用してレポートplogファイルを開きます。

さて、ここで最も興味深いのは、エラーの検索です。

Wiresharkプロジェクトでエラーを見つける

PVS-Studioの警告を見て、IntelliSenseナビゲーションを使用して、エラーの検索を開始しましょう。

最初から、コード内のコメントに惹かれました。

void decode_ex_CosNaming_NamingContext_NotFound(....) { .... (void)item; /* Avoid coverity param_set_but_unused parse warning */ .... /* coverity[returned_pointer] */ item = proto_tree_add_uint(....); .... }

ほとんどの場合、Wiresharkプロジェクトは、高い信頼性を必要とするプロジェクトで使用される静的Coverityアナライザーによって既に定期的にチェックされています。そのようなプロジェクトには、医療機器用、原子力プラント用、航空用、そして最近では組み込みシステム用のソフトウェアが含まれます。したがって、コベリティが見逃したエラーを見つけることは興味深いでしょう。

PVS-Studioの機能の全体像を形成するために、テスト中の未定義の動作のために検出が困難なさまざまなタイプのエラーを探します。C/ C ++言語の高度な知識が必要で、単に興味深いものです。このためには、2番目のレベルの最初の大まかな警告で十分です。

コード：

 typedef struct AIRPDCAP_SEC_ASSOCIATION { .... AIRPDCAP_KEY_ITEM *key; .... }; void AirPDcapWepMng(....,AIRPDCAP_KEY_ITEM* key, AIRPDCAP_SEC_ASSOCIATION *sa, ....) { .... memcpy(key, &sa->key, sizeof(AIRPDCAP_KEY_ITEM)); .... }

警告： V512 「memcpy」関数を呼び出すと、「＆sa-> key」バッファーが範囲外になります。 airpdcap.c 1192

C / C ++言語は、読み取りおよび書き込み中の配列の境界の組み込みチェックがないため、RAMで効果的な低レベルの作業を提供します。メモリバッファの充填、コピー、および比較のエラーは、未定義のプログラムの動作または検出が困難なセグメンテーションエラーにつながる可能性があります。

アドレス 'key'にある構造 'AIRPDCAP_KEY_ITEM'を埋めるために、それは使用される同じ構造へのアドレス 'sa-> key'ではなく、それへのポインターのアドレスです。このエラーを修正するには、アドレス「＆」を取得する不要な操作を削除するだけです。

コード：

 typedef struct _h323_calls_info { e_guid_t *guid; .... } h323_calls_info_t; static const e_guid_t guid_allzero = {0, 0, 0, { 0, 0, 0, 0, 0, 0, 0, 0 } }; void q931_calls_packet(....) { h323_calls_info_t *tmp2_h323info; .... memcmp(&tmp2_h323info->guid, &guid_allzero, 16) == 0; .... }

警告： V512 「memcmp」関数を呼び出すと、バッファー「＆tmp2_h323info-> guid」がオーバーフローします。 voip_calls.c 1570

バッファの不適切な使用に関する別の例。関数 'memcmp（）'の引数の1つで、構造体 'e_guid_t'へのポインターへのポインターが、ポインターへではなく渡されます。

コード：

 #define ETHERCAT_MBOX_HEADER_LEN ((int) sizeof(ETHERCAT_MBOX_HEADER)) void dissect_ecat_datagram(....) { if (len >= sizeof(ETHERCAT_MBOX_HEADER_LEN) && ....) { .... } }

警告： V568 sizeof（）演算子の引数が '（int）sizeof（ETHERCAT_MBOX_HEADER）'式であることは奇妙です。 packet-ethercat-datagram.c 519

C ++でメモリを操作する場合、演算子 'sizeof（）'が使用され、オブジェクトまたはバッファーのサイズがバイト単位で返されます。この場合、「sizeof（）」は、構造体「ETHERCAT_MBOX_HEADER」のサイズの代わりに、タイプ「int」のサイズをバイト単位で返します。エラーを修正するには、余分な操作 'sizeof（）'を削除します。

コード：

 void Proto_new(....) { .... if (!name[0] || !desc[0]) luaL_argerror(L,WSLUA_ARG_Proto_new_NAME, "must not be an empty string"); .... if ( name ) { .... loname_a = g_ascii_strdown(name, -1); .... } .... }

警告： V595 nullptrに対して検証される前に、「名前」ポインターが使用されました。チェック行：1499、1502 wslua_proto.c 1499

通常、ポインターがオブジェクトを参照していないことを示すために、特別なヌル値がオブジェクトに書き込まれ、ポインターを使用する前に追加のチェックが行われます。静的分析により、セキュリティに違反する可能性のある欠落したチェック、およびコードを大幅に混乱させる冗長なチェックを見つけることができます。

ポインター「name」の確認は、「name [0]」を使用した後に行われます。一方では、ポインターがnullでない場合、このチェックは冗長であり、他方では、nullの場合、エラーが発生します。

コード：

 void create_byte_graph(....) { .... u_data->assoc=(sctp_assoc_info_t*)g_malloc( sizeof(sctp_assoc_info_t)); u_data->assoc=userdata->assoc; .... }

警告： V519 「u_data-> assoc」変数には、連続して2回値が割り当てられます。おそらくこれは間違いです。行を確認してください：1526、1527。sctp_byte_graph_dlg.c 1527

C / C ++では、メモリの割り当てと割り当て解除は手動で行われます。メモリ割り当てエラーが失敗すると、メモリリークが発生する場合があります。

関数 'g_malloc（）'は、サイズ 'sizeof（sctp_assoc_info_t）'バイトの動的メモリの一部を割り当て、それへのポインタを返します。ただし、このポインターを格納する変数の値を変更した後は、このセクションにアクセスしたり解放したりできなくなり、メモリリークが発生します。

コード：

 PacketList::PacketList(QWidget *parent) { QMenu *submenu; .... submenu = new QMenu(tr("Colorize with Filter")); /*ctx_menu_.addMenu(submenu);*/ submenu = new QMenu(tr("Copy")); ctx_menu_.addMenu(submenu); .... }

警告： V519 「サブメニュー」変数には、連続して2回値が割り当てられます。おそらくこれは間違いです。行を確認：287、363。packet_list.cpp 363

デザイナーは視覚的なインターフェイス要素を動的に作成し、Qtオブジェクト階層に追加します。これにより、最上位オブジェクトが削除されたときに、作成されたオブジェクトを再帰的に破棄できます。ただし、メニュー項目の1つがオブジェクト階層に追加されていないため、メモリリークが発生します。

コード：

 void dissect_display_switch(gint offset, guint msg_len, ....) { .... if((address_byte&DISPLAY_WRITE_ADDRESS_LINE_FLAG) !=DISPLAY_WRITE_ADDRESS_LINE_FLAG) offset+=1;msg_len-=1; .... }

警告： V640コードの操作ロジックはそのフォーマットに対応していません。 2番目のステートメントは常に実行されます。中括弧が欠落している可能性があります。 packet-unistim.c 1134

条件文「if」のブロックを強調表示する中括弧「{}」の誤った配置は、エラーにつながる可能性があります。

条件演算子「if」の本体は1つの命令で構成されますが、フォーマットとプログラムロジックには複数の命令が必要です。エラーを修正するには、いくつかの指示を中括弧「{}」で囲む必要があります。

コード：

 void dissect_ssc_readposition (....) { .... switch (service_action) { .... case LONG_FORM: if (!(flags & MPU)) { .... } else /*offset += 16;*/ break; .... } .... }

警告： V705 「else」ブロックが忘れられているか、コメント化されている可能性があります。そのため、プログラムの操作ロジックが変更されています。 packet-scsi-ssc.c 831

面白いですが、1つのコメントだけでプログラムのロジックが変更される可能性があります。ブロック「case LONG_FORM」の終了は、「else」がトリガーされたときにのみ実行され、必然的にエラーが発生します。

コード：

 void set_has_console(gboolean set_has_console) { has_console = has_console; }

警告： V570 「has_console」変数はそれ自体に割り当てられます。 console_win32.c 235

不注意に関連するエラーもあります。関数 'set_has_console（）'は 'has_console'の値を 'set_has_console'に変更することになっていますが、これは起こりません。エラーを修正するには、「has_console」変数に「set_has_console」引数で渡された値を割り当てる必要があります。

コード：

 void dissect_dcc(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree, void *data _U_) { client_is_le = ( (tvb_get_guint8(tvb, offset+4) | tvb_get_guint8(tvb, offset+4)) &&(tvb_get_guint8(tvb, offset+8) | tvb_get_guint8(tvb, offset+9)) && (tvb_get_guint8(tvb, offset+12) | tvb_get_guint8(tvb, offset+13)) ); }

警告： V501 「|」の左と右に同一のサブ式「tvb_get_guint8（tvb、オフセット+ 4）」があります演算子。 packet-dcc.c 272

式tvb_get_guint8（tvb、オフセット+ 4）が繰り返されます。類推により、tvb_get_guint8（tvb、offset + 5）の書き込みを計画していると想定できます。

記事を煩雑にしないために、私が書いていない他の間違いがありました。与えられた例は、静的解析の可能性を示し、PVS-Studioに人々の注意を引くのに十分なはずです。 PVS-Studioの機能の全体像を把握する必要がある場合は、サイトで考えられるすべての警告のリストを見つけることができます。 Wiresharkのより徹底的な分析は、開発者自身が行うことができます。彼らが何かが間違いであるかどうかを理解することは彼らにとってはるかに簡単です。

おわりに

疑わしいコードのセクションはそれほど多くありませんでした。おそらく、私たちがコメントを見たCoverity静的アナライザーの使用によるものです。したがって、コードを作成する段階でテストする前でもエラーを検出するために、プロジェクトで静的アナライザーを定期的に使用することを全員に推奨します。

プログラミングが成功し、間違いが減ることを願っています。

この記事を英語圏の聴衆と共有したい場合は、翻訳へのリンクを使用してください：Andrey Kalashnikov。 PVS-StudioによるWiresharkの静的解析。

記事を読んで質問がありますか？

多くの場合、記事には同じ質問が寄せられます。ここで回答を収集しました： PVS-StudioおよびCppCatバージョン2015に関する記事の読者からの質問への回答。リストをご覧ください。

PVS-Studioを使用したWiresharkの静的分析