エラーおよび潜在的な脆弱性を検索するためにPVS-Studioコードアナライザーで使用されるテクノロジー

多数のエラーパターンと潜在的な脆弱性を効果的に検出できるPVS-Studioツールで使用されるテクノロジーの簡単な説明。 この記事では、CおよびC ++コードのアナライザーの実装について説明していますが、上記の情報は、C＃およびJavaコードの分析を担当するモジュールにも有効です。

はじめに

静的コードアナライザーは非常に単純なプログラムであり、正規表現を使用したコードパターンの検索に基づいているという誤解があります。 これは真実とは程遠い。 さらに、正規表現を使用してエラーの大部分を識別することは、単に不可能です。



このエラーは、10〜20年前に存在していたいくつかのツールを使用したプログラマーの経験に基づいて発生しました。 多くの場合、ツールの作業は、コードやstrcpy 、 strcatなどの関数の危険なパターンを見つけることになりました。 このクラスのツールの代表としてRATSと呼ぶことができます。



このようなツールは有用ではありますが、一般的に愚かで効果がありません。 多くのプログラマーがいまだに記憶を持っているのは、静的アナライザーが非常に役に立たないツールであり、それを助けるよりも仕事に干渉するということです。



時間が経ち、静的アナライザーは、綿密なコード分析を実行し、注意深いコードレビューの後でもコードに残っているエラーを見つける複雑なソリューションを構成し始めました。 残念ながら、過去の否定的な経験により、多くのプログラマーは静的分析手法を役に立たないと考えており、開発プロセスに導入することを急いでいません。



この記事では、状況を少し修正しようとします。 読者に、エラーを検出するためにPVS-Studio静的コードアナライザーで使用されているテクノロジーを理解するのに15分かかるようにお願いします。 おそらくその後、静的解析のツールを新たに見て、それらを作業に適用したいと思うでしょう。

データフロー分析

データストリームの分析により、さまざまなエラーを見つけることができます。 その中には、配列の範囲外への出入り、メモリリーク、常にtrue / false条件、nullポインターの逆参照などがあります。



また、データ分析を使用して、外部からプログラムに送られた未検証データが使用されている状況を検索できます。 攻撃者は、このような一連の入力データを準備して、プログラムを必要な方法で機能させることができます。 言い換えれば、不十分な入力制御のエラーを脆弱性として使用する可能性があります。 PVS-Studioで未検証データの使用を検索するために、特殊な診断V1010が実装され、改善が続けられています。



データフローの分析 （ Data-Flow Analysis ）は、コンピュータープログラムのさまざまなポイントで変数の可能な値を計算することです。 たとえば、ポインターが間接参照されており、この時点でポインターがゼロになることがわかっている場合、これはエラーであり、静的アナライザーはそれを報告します。



データフロー分析を使用してエラーを探す実際的な例を見てみましょう。 日付の正しさをチェックするように設計されたProtocol Buffers（protobuf）プロジェクトの関数があります。

static const int kDaysInMonth[13] = { 0, 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 }; bool ValidateDateTime(const DateTime& time) { if (time.year < 1 || time.year > 9999 || time.month < 1 || time.month > 12 || time.day < 1 || time.day > 31 || time.hour < 0 || time.hour > 23 || time.minute < 0 || time.minute > 59 || time.second < 0 || time.second > 59) { return false; } if (time.month == 2 && IsLeapYear(time.year)) { return time.month <= kDaysInMonth[time.month] + 1; } else { return time.month <= kDaysInMonth[time.month]; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studioアナライザーは、関数で2つの論理エラーを検出し、次のメッセージを表示します。

• V547 / CWE-571式 'time.month <= kDaysInMonth [time.month] + 1'は常にtrueです。 time.cc 83
• V547 / CWE-571式 'time.month <= kDaysInMonth [time.month]'は常にtrueです。 time.cc 85

部分式「time.month <1 || time.month> 12 "。 月の値が範囲[1..12]の外にある場合、関数は作業を停止します。 アナライザーはこれを考慮して、2番目のifステートメントの実行が開始された場合、 月の値が正確に[1..12]の範囲にあることを認識します。 同様に、彼は他の変数の範囲（年、日など）を知っていますが、今ではそれらは私たちにとって興味深いものではありません。



ここで、配列要素にアクセスするための2つの同一の演算子kDaysInMonth [time.month]を見てみましょう。



配列は静的に設定され、アナライザーはそのすべての要素の値を知っています。

 static const int kDaysInMonth[13] = { 0, 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

月には1から番号が付けられるため、アナライザーは配列の先頭で0を考慮しません。 [28..31]の範囲の値を配列から抽出できることがわかりました。



年がうるう年かどうかに応じて、日数に1が追加されますが、これは今では興味の対象ではありません。 比較自体は重要です。

 time.month <= kDaysInMonth[time.month] + 1; time.month <= kDaysInMonth[time.month];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

範囲[1..12]（月数）は、その月の日数と比較されます。



最初の場合、月は常に2月（ time.month == 2 ）であることを考慮すると、次の範囲が比較されることがわかります。

• 2 <= 29
• [1..12] <= [28..31]

ご覧のとおり、比較の結果は常に真であり、PVS-Studioアナライザーは警告しています。 実際、コードには2つの同じタイプミスが含まれています。 式の左側では、 月ではなく、 日クラスのメンバーを使用する必要があります。



正しいコードは次のようになります。

 if (time.month == 2 && IsLeapYear(time.year)) { return time.day <= kDaysInMonth[time.month] + 1; } else { return time.day <= kDaysInMonth[time.month]; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで説明したエラーは、「 2月31日 」の記事でも説明されています。

シンボリック実行

前のセクションでは、アナライザーが変数の可能な値を計算する方法を検討しました。 ただし、いくつかのエラーを見つけるために、変数の値を知る必要はありません。 シンボリック実行には、シンボリック方程式の解法が含まれます。



エラーデータベースに適切なデモが見つかりませんでしたので、合成コードの例を検討してください 。

 int Foo(int A, int B) { if (A == B) return 10 / (A - B); return 1; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studioアナライザーは、警告V609 / CWE-369 Divide by zeroを生成します。 分母 'A-B' ==0。test.cpp 12



変数AおよびBの値は、アナライザーにとって不明です。 しかし、アナライザーは式10 /（A-B）を計算する時点で、変数AとBが等しいことを知っています。 したがって、0による除算が発生します。



AとBの値は不明だと言いました。 一般的な場合、これは事実です。 ただし、アナライザーが実際の引数の特定の値を持つ関数呼び出しを検出した場合、これは考慮されます。 例を考えてみましょう：

 int Div(int X) { return 10 / X; } void Foo() { for (int i = 0; i < 5; ++i) Div(i); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studioアナライザーはゼロ除算を警告します：V609 CWE-628ゼロ除算。 分母 'X' ==0。'Div '関数は値' [0..4] 'を処理します。 最初の引数を調べます。 行を確認：106、110。consoleapplication2017.cpp 106



ここでは、データフロー分析、シンボリック実行、および自動メソッドアノテーションのテクノロジーの組み合わせが既に機能しています（このテクノロジーについては次のセクションで説明します）。 アナライザーは、変数Xが Div関数の除数として使用されていることを確認します。 これに基づいて、 Div関数用の特別な注釈が自動的に構築されます。 さらに、値の範囲[0..4]が引数Xとして関数に渡されることも考慮されます。 アナライザーは、0による除算が発生すると結論付けます。

メソッド注釈

私たちのチームは、以下で提供される数千の関数とクラスに注釈を付けています。

• ウィナピ
• C標準ライブラリ
• 標準テンプレートライブラリ（STL）、
• glibc（GNU Cライブラリ）
• Qt
• Mfc
• zlib
• libpng
• Openssl
• などなど

すべての機能には手動で注釈が付けられます。これにより、エラーの検出に関して重要な多くの特性を設定できます。 たとえば、 fread関数に渡されるバッファーのサイズは、ファイルから読み取る予定のバイト数以上でなければならないことが指定されています。 2番目、3番目の引数と関数が返すことができる値の関係も示されています。 すべて次のようになります。

この注釈のおかげで、 fread関数を使用する次のコードは2つのエラーをすぐに明らかにします。

 void Foo(FILE *f) { char buf[100]; size_t i = fread(buf, sizeof(char), 1000, f); buf[i] = 1; .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studioの警告：

• V512 CWE-119「fread」関数を呼び出すと、バッファー「buf」がオーバーフローします。 test.cpp 116
• V557 CWE-787アレイのオーバーランが可能です。 「i」インデックスの値は1000に達する可能性があります。test.cpp 117

最初に、アナライザーは2番目と3番目の実引数を乗算し、関数が最大1000バイトのデータを読み取れることを計算しました。 同時に、バッファサイズは100バイトしかないため、オーバーフローする可能性があります。



第二に、関数は1000バイトまで読み取ることができるため、変数iの可能な値の範囲は[0..1000]です。 したがって、配列へのアクセスは間違ったインデックスで発生する可能性があります。



エラーの別の簡単な例を見てみましょう。エラーの検出は、 memset関数のマークアップのおかげで可能になりました。 CryEngine V.プロジェクトのコードスニペットを次に示します。

 void EnableFloatExceptions(....) { .... CONTEXT ctx; memset(&ctx, sizeof(ctx), 0); .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studioアナライザーはタイプミスを見つけました：V575「memset」関数は「0」要素を処理します。 3番目の引数を調べます。 crythreadutil_win32.h 294



関数の2番目と3番目の引数を混同しました。 その結果、関数は0バイトを処理し、何もしません。 アナライザーはこの異常に気付き、プログラマーに警告します。 以前、「 CryEngine Vの待望のチェック 」という記事でこのエラーについて既に説明しました。



PVS-Studioアナライザーは、手動で設定した注釈に限定されません。 さらに、彼は独自に関数の本体を調べて注釈を作成しようとします。 これにより、関数の不適切な使用のエラーを見つけることができます。 たとえば、アナライザーは、関数がnullptrを返すことができることを記憶しています。 この関数によって返されたポインターが事前チェックなしで使用される場合、アナライザーはそれについて警告します。 例：

 int GlobalInt; int *Get() { return (rand() % 2) ? nullptr : &GlobalInt; } void Use() { *Get() = 1; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

警告：V522 CWE-690潜在的なヌルポインター 'Get（）'の逆参照が存在する可能性があります。 test.cpp 129



ご注意 逆の方法で調べたばかりのエラーの検索にアプローチできます。 何も覚えてはいけません。Get関数の呼び出しが発生するたびに、実際の引数を知って分析してください。 このようなアルゴリズムにより、理論的にはより多くのエラーを見つけることができますが、指数関数的に複雑になります。 プログラムの分析時間は数十万回になりますが、このアプローチは実用的な観点から行き止まりだと考えています。 PVS-Studioでは、関数の自動注釈の方向性を開発しています。

パターンマッチング

パターンとのテクノロジーマッチングは、一見すると、正規表現を使用した検索のように見えます。 実際、これはそうではなく、すべてがはるかに複雑です。



まず、すでに述べたように 、正規表現は一般に価値がありません。 第二に、アナライザーはテキスト行ではなく、より複雑で高レベルのエラーパターンを認識できる構文ツリーで機能します。



2つの例を考えてみましょう。1つはより単純で、もう1つはより複雑です。 私が見つけた最初のエラーは、Androidのソースコードをチェックすることでした。

 void TagMonitor::parseTagsToMonitor(String8 tagNames) { std::lock_guard<std::mutex> lock(mMonitorMutex); if (ssize_t idx = tagNames.find("3a") != -1) { ssize_t end = tagNames.find(",", idx); char* start = tagNames.lockBuffer(tagNames.size()); start[idx] = '\0'; .... } .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studioアナライザーは、C ++の操作の優先順位に関するプログラマーの誤解に関連する古典的なエラーパターンを認識します。V593/ CWE-783「A = B！= C」の表現を検討してください。 式は次のように計算されます： 'A =（B！= C）'。 TagMonitor.cpp 50



この行をよく見てください：

 if (ssize_t idx = tagNames.find("3a") != -1) {
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

プログラマーは、割り当てが最初に実行され、その後のみ-1との比較が実行されると想定します。 実際、比較が最初になります。 クラシック このエラーについては、Android検証に関する記事で詳しく説明しています （「その他のエラー」の章を参照）。



ここで、高レベルのパターンマッチングオプションを検討します。

 static inline void sha1ProcessChunk(....) { .... quint8 chunkBuffer[64]; .... #ifdef SHA1_WIPE_VARIABLES .... memset(chunkBuffer, 0, 64); #endif }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studio警告：V597 CWE-14コンパイラは、「memset」関数呼び出しを削除できます。これは、「chunkBuffer」バッファーのフラッシュに使用されます。 RtlSecureZeroMemory（）関数を使用して、プライベートデータを消去する必要があります。 sha1.cpp 189



問題の本質は、 memset関数を使用してバッファをゼロで埋めた後、このバッファはどこでも使用されないことです。 最適化フラグを使用してコードをコンパイルすると、コンパイラはこの関数呼び出しが冗長であると判断し、削除します。 C ++言語の観点からは、関数の呼び出しにはプログラム上で観察可能な動作がないため、彼にはこれに対する権利があります。 chunkBufferバッファーを埋めた直後に、 sha1ProcessChunk関数は終了します。 バッファはスタック上に作成されるため、関数を終了すると使用できなくなります。 したがって、コンパイラーの観点からは、ゼロで埋めても意味がありません。



その結果、スタック上のどこかにプライベートデータが残り、トラブルにつながる可能性があります。 このトピックの詳細については、「 プライベートデータの安全なクリーニング 」を参照してください。



これは、高度なパターンマッチングの例です。 まず、アナライザーは、この脆弱性の存在を認識している必要があります。これは、Common Weakness Enumerationに従ってCWE-14：Compiler Removal of Code to Clear Buffersとして分類されています。



第二に、スタック上でバッファが作成されるすべての場所をコード内で見つける必要があり、 memset関数を使用して消去され、他の場所では使用されません。

おわりに

ご覧のとおり、静的解析は非常に興味深く有用な方法論です。 これにより、初期段階で多数のエラーと潜在的な脆弱性を排除できます（ SASTを参照）。 まだ静的解析を完全に行っていない場合は、 ブログをご覧ください。さまざまなプロジェクトでPVS-Studioを使用して検出されたエラーを定期的に分析しています。 あなたは単に無関心でいることはできません。



お客様の中に貴社をご紹介し、お客様のアプリケーションをより良く、より信頼性が高く、より安全にするお手伝いをさせていただきます。

この記事を英語圏の聴衆と共有したい場合は、翻訳へのリンクを使用してください：Andrey Karpov。 バグや潜在的な脆弱性を見つけるためにPVS-Studioコードアナライザーで使用されるテクノロジー 。