UB 2017。 パート1

CおよびC ++の未定義動作（UB）に起因する問題は、主にASan、UBSan、MSan、TSanなどの動的検証ツールを広く使用することで解決されると主張する人もいます。 ここで明らかなことを示します。近年、これらのツールには多くの素晴らしい改善がありましたが、UBの問題はまだ解決されておらず、状況を詳細に検討します。







Valgrindおよびほとんどのサニタイザーはデバッグを目的としています。テスト中に発生した未定義の動作のケースに関連するわかりやすい診断メッセージを生成します。 このようなツールは非常に有用であり、ほとんどすべての非自明なCおよびC ++プログラムが継続的なUBフローとして実行される世界の状態から、最も一般的な構成およびユースケースでかなりの数の重要なプログラムがほとんどUBフリーである世界の状態に進化するのに役立ちます。



ダイナミックデバッグツールの問題は、UBの最悪のケースに対処するために何もしないことです。テスト中にどのように動作するかはわかりませんが、リリースでUBがどのように表示されるかは他の誰かが理解できます脆弱性として使用します。 問題は、品質テストに要約されますが、これは困難です。 afl-fuzzのようなツールは優れていますが、大きなプログラムに触れることさえほとんどありません。 テストの問題を回避する1つの方法は、静的UB検出ツールを使用することです。 それらは絶えず改善されていますが、自信を持って正確な静的解析を行うのは必ずしも良いテストカバレッジを達成するよりも簡単ではありません。 もちろん、これらの2つの手法は、1つの問題を解決することを目的としており、プログラムを実行する方法を異なる角度から特定します。 この問題は常に非常に複雑であり、おそらく常にそうです。 静的分析を通じてUBを見つけることについて多くのことが書かれていますが、この記事では動的ツールに焦点を当てます。 テストの問題を解決するもう1つの方法は、UB「緩和」ツールを使用することです。CおよびC ++を使用すると未定義の動作を定義済みの動作に変換し、安全なプログラミング言語を使用する利点を効果的に達成します。 UBを軽減するツールの設計の難しさは次のとおりです。



-「角」の場合（角の場合）にコードを壊さないでください

-オーバーヘッドが少ない

-追加の脆弱性を追加しないでください。たとえば、未チェックのランタイムライブラリとのリンクが必要です。

-攻撃を困難にする

-相互に組み合わせる（対照的に、ASanやTSanなどの一部のデバッグツールは互換性がなく、両方のツールを必要とするプロジェクトに対してテストスイートを2回実行する必要があります）。



UBの個々のケースを見る前に、目標を定義しましょう。 すべてのCおよびC ++コンパイラに適用されます。



目標1： UBの各ケース（はい、約200個あり、最後に完全なリストを提供します）は、特定の動作があると文書化するか、コンパイラによって致命的なエラーとして診断されるか、最後の手段として、UBを検出するサニタイザーを使用する必要がありますランタイム。 これは、論争を引き起こすべきではありません。これは、攻撃者がネットワークパケットとコンパイラの最適化を使用できる現代のCおよびC ++での開発の最小要件のようなものです。



目標2：各UBのケースは、文書化されるか、致命的なエラーとしてコンパイラによって診断されるか、以前の要件を満たすオプションの「緩和」メカニズムを持つ必要があります。 これは難しいです。 これは多くのプラットフォームで達成できると考えています。 速度が重要なオペレーティングシステムや他のコードのカーネルは、正式な方法など、他のテクノロジーを使用する必要があります。 この記事の残りの部分では、不定の動作のさまざまなクラスの現在の状況を調べます。



大きなUBクラスから始めましょう。

空間メモリの安全違反

説明：リポジトリの外部にアクセスし、そのようなポインターを作成することさえ、CおよびC ++のUBです。 1988年、Morrisワームは、今後N年間で私たちを待っていることを示唆しました。 私たちが知っているように、N> = 29、そしておそらくNの値は75に達するでしょう。



デバッグ： ValgrindとASanは優れたデバッグツールです。 多くの場合、ASanはオーバーヘッドが少ないため優れています。 どちらのツールもアドレスを32ビット値または64ビット値として表し、有効なブロックの周囲に禁止されたレッドゾーンを予約します。 これは信頼できるアプローチであり、このツールを使用する通常のバイナリライブラリとシームレスに連携できます。また、ポインターを整数に変換する操作を持つ通常のコードもサポートします。



Valgrindは実行可能コードから機能し、スタック変数の間にレッドゾーンを挿入できません。 スタック上のオブジェクトの配置は、スタックにアクセスする命令のオフセット値にすでにエンコードされており、スタックにアクセスするアドレスを「オンザフライ」で変更することはできません。 その結果、Valgrindはスタック上のオブジェクトを操作してエラーを検出する際のサポートを制限しています。 ASanはコンパイル時に実行され、スタック変数の周りにレッドゾーンを挿入します。 スタック変数は小さく多数あり、アドレス空間とローカリティを考慮すると、非常に大きなレッドゾーンの使用が妨げられます。 デフォルト設定では、2つの隣接するローカル整数変数xとyのアドレスは16バイトで区切られます。 つまり、ASanおよびValgrindによって生成される検証は、メモリ内のオブジェクトの配置のみに関連し、検証が有効な場合のオブジェクトの配置は、検証ツールを使用しないオブジェクトの配置とは異なります。



ASanとValgrindの欠点は、例のように、オプティマイザーによってコードが削除されて実行できない場合、UBをスキップできることです。



緩和策 ：ASLR、「スタックカナリア」、「保護されたアロケーター」、NXビットなど、安全でないメモリ操作に対する緩和メカニズムが長い間ありました。















その後、生産グレードのCFI（制御フローの整合性制御）が利用可能になりました。 別の興味深い最近の開発は、ARMv8.3のポインター識別です。 この記事では、メモリセキュリティに関連するUB緩和策の概要を説明します。



UBを緩和する手段としてのASanの重大な欠陥を以下に示します。

$ cat asan-defeat.c #include <stdio.h> #include <stdlib.h> #include <string.h> char a[128]; char b[128]; int main(int argc, char *argv[]) { strcpy(a + atoi(argv[1]), "owned."); printf("%s\n", b); return 0; } $ clang-4.0 -O asan-defeat.c $ ./a.out 128 owned. $ clang-4.0 -O -fsanitize=address -fno-common asan-defeat.c $ ./a.out 160 owned. $
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

言い換えれば、ASanは、メモリの目的の領域を損なうために、単に攻撃者に異なるオフセットを計算させるだけです。 （ASanで-fno-commonフラグの使用を促すYuri Gribovに感謝します。）



未定義の動作のこのバリアントを緩和するには、有効な領域で各メモリアクセスが発生するかどうかの単純なチェックではなく、境界を越える実際のチェックを実行する必要があります。 ここでは、メモリセキュリティがゴールドスタンダードです。 メモリセキュリティに関する多くの学術論文があり、合理的なオーバーヘッドと既存のソフトウェアとの良好な互換性を備えたアプローチを示すものもありますが、広く使用されていません。 Checked Cisは、この分野で非常にクールなプロジェクトです。



結論：この種のエラーのデバッグツールは非常に優れています。 このタイプのUBを大幅に軽減することは可能ですが、完全に排除するには、完全なタイプとメモリのセキュリティが必要です。

一時記憶の安全違反

説明：一時メモリオブジェクトのセキュリティ違反は、その有効期限が切れた後のメモリロケーションの使用です。 これには、これらの変数の範囲外の自動変数のアドレス指定、リリース後の使用、読み取りまたは書き込みへのダングリングポインターの使用、ダブルリリースが含まれます。これは、実際には非常に危険です。 free（）は、通常、解放されるブロックに属するメタデータを変更します。 ブロックがすでに解放されている場合、このデータへの書き込みは、他の目的で使用されるデータに損傷を与える可能性があり、原則として、他の無効なレコードと同じ結果をもたらす可能性があります。



デバッグ： ASanは、「リリース後の使用」バグを検出するように設計されています。これは、再現が難しく、誤った動作を引き起こすことがよくあります。 彼は、解放されたブロックを隔離し、即座に再利用することを防ぎます。 一部のプログラムおよび入力では、これによりメモリ消費が増加し、局所性が低下する場合があります。 ユーザーは、誤検知とリソース使用率の妥協点を見つけるために隔離サイズを設定できます。



ASanは、これらの変数の範囲を超えて生き残る自動変数のアドレスも検出できます。 アイデアは、自動変数を動的メモリに割り当てられたブロックに変換することです。これは、実行がブロックに入るとコンパイラが自動的に割り当て、実行がブロックを離れると解放します（検疫中）。 このオプションは、メモリの点でプログラムをさらに貪欲にしたいため、デフォルトでは無効になっています。



以下のプログラムで一時メモリオブジェクトのセキュリティに違反すると、デフォルトの最適化と-O2の間の動作に違いが生じます。 ASanは最適化なしでプログラムの問題を検出できますが、detect_stack_use_after_returnオプションが設定されている場合、および最適化を使用してコンパイルされていない場合のみです。

 $ cat temporal.c #include <stdio.h> int *G; int f(void) { int l = 1; int res = *G; G = &l; return res; } int main(void) { int x = 2; G = &x; f(); printf("%d\n", f()); } $ clang -Wall -fsanitize=address temporal.c $ ./a.out 1 $ ASAN_OPTIONS=detect_stack_use_after_return=1 ./a.out ================================================================= ==5425==ERROR: AddressSanitizer: stack-use-after-return ... READ of size 4 at 0x0001035b6060 thread T0 ^C $ clang -Wall -fsanitize=address -O2 temporal.c $ ./a.out 32767 $ ASAN_OPTIONS=detect_stack_use_after_return=1 ./a.out 32767 $ clang -v Apple LLVM version 8.0.0 (clang-800.0.42.1) ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

他のいくつかの例では、サニタイザーはオプティマイザーによって削除されたUBを検出できず、したがってUBを使用したリモートコードでは結果を得ることができないため、安全です。 しかし、これはそうではありません！ プログラムはどんな場合でも意味がありませんが、変数xが静的に宣言されているかのように、最適化されていないプログラムは決定論的に動作し、ASanが疑わしいものを見つけなかった最適化プログラムは決定論的に動作し、意図しない内部状態を明らかにします見ることができました：

 $ clang -Wall -O2 temporal.c $ ./a.out 1620344886 $ ./a.out 1734516790 $ ./a.out 1777709110
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

緩和策：上記で説明したように、ASanは脆弱性から保護するようには設計されていませんが、さまざまな保護されたアロケーターが使用可能であり、同じ検疫戦略を使用して「使用後の脆弱性」を閉じます。



結論： ASanを使用します（小規模な場合のテストには、「ASAN_OPTIONS = detect_stack_use_after_return = 1」とともに）。 さまざまなレベルの最適化で、他のレベルでは捕捉されないエラーを捕捉できます。

整数オーバーフロー

説明：整数のオーバーフローはありませんが、両方向にオーバーフローが発生する可能性があります。 UB

ゼロによる除算と、数値の桁数より大きい値によるシフトは、符号付き数値と符号なし数値の両方でUBです。 参照： C / C ++の整数オーバーフローについて



デバッグ： UBSanは、整数に関連付けられたUBを見つけるための非常に優れたツールです。 UBSanはソースレベルで動作するため、非常に信頼できます。 コンパイル時の計算に関していくつかの奇妙な点があります。たとえば、一部のプログラムは、C ++ 11としてコンパイルされた場合に例外をキャッチする可能性があり、C11でコンパイルするときに例外をキャッチしません。標準に準拠していると考えていますが、詳細には触れていません GCCには独自のバージョンのUBSanがありますが、100％信頼することはできません。このツールがパスする前に定数が崩壊します。



軽減： 「トラップモード」のUBSan（UBがキャッチされると、診断出力なしでプロセスが停止します）を使用して、UBを軽減できます。 これは効果的であり、脆弱性を追加しません。 一部では、AndroidはUBSanを使用してこのタイプのUBを緩和します。 整数のオーバーフローは基本的に論理的な間違いですが、CおよびC ++では、このようなエラーはメモリセキュリティ違反につながる可能性があるため、特に危険です。 メモリへの安全なアクセスを備えた言語では、それらはそれほど危険ではありません。



結論：整数UBをキャッチするのはそれほど難しくありません、UBSan、これで必要なのはそれだけです。 問題は、整数UBを軟化すると冗長性が生じることです。 たとえば、SPEC CPU 2006は30％遅くなります。 改善の余地はたくさんあります。また、破損する可能性のあるオーバーフローチェックを排除し、残りのチェックのループオプティマイザーへの干渉を軽減します。 十分なリソースを持つ人がこれを行う必要があります。

厳格なエイリアシング違反

説明： CおよびC ++標準の厳密なエイリアスルールにより、コンパイラは、2つのポインタが異なる型を参照する場合、同じオブジェクトを指していないとコンパイラが想定できるようになります。これにより、優れた最適化が可能になりますが、プログラムをより柔軟に見直すリスクがあります（これは、大まかな推定によると、大規模なCおよびC ++プログラムの100％です。）詳細なレビューについては、この記事のセクション1-3を参照してください（ 次のパートで公開されます。約transl。 ）。



デバッグ：厳密なエイリアス違反に対するデバッグツールの現在の状態は脆弱です。 コンパイラーはいくつかの単純なケースで警告を出しますが、これらの警告は非常に信頼できません。 libcrunchは、ポインターが「何かへのポインター」タイプに変換されることを警告しますが、実際には他の何かを指します。 これにより、voidへのポインターを介して型変換を実行できますが、このタイプのUBでもある誤ったポインター変換をキャッチします。 C標準とCコンパイラがTBAAを最適化するときに何ができるかを解釈する方法（タイプベースのエイリアス分析）のおかげで、libcrunchは信頼性がありません（プログラム実行中に発生するいくつかの違反をキャッチしません）疑わしいと思われるが標準に違反していない場合のポインターの変換について）。



緩和策：簡単です：フラグ（-fno-strict-aliasing）をコンパイラーに渡すと、厳密なエイリアスベースの最適化が無効になります。 その結果、コンパイラは、ポインタ型間の多かれ少なかれ任意の変換を実行できる古き良きメモリモデルに依存し、結果のコードは期待どおりに動作します。 ビッグスリーのうち、GCCとLLVMのみがこのようなUBの対象であり、MSVCはそのようなクラスの最適化を実装しません。



結論：このUBに敏感なコードは注意深くチェックする必要があります：ポインターをchar *以外のものに変換することは常に疑わしく危険です。 別の方法として、フラグを使用してTBAA最適化をオフにし、このフラグを使用しないとコードがコンパイルされないようにすることができます。

アライメント違反

説明： RISCプロセッサは、非境界整列アドレスでのメモリアクセスを拒否する傾向があります。 一方、不均衡なアクセスを使用するCおよびC ++プログラムには、ターゲットアーキテクチャに関係なくUBがあります。 歴史的には、最初にx86 / x64が不均衡なアクセスをサポートするため、そしてコンパイラがまだこのUBを最適化に使用していないため、これを指で見てきました。 しかし、この場合でも、コンパイラがx64での非境界整列アクセスでコードを破壊する方法を説明する素晴らしい記事があります。 この記事のコードは、-fno-strict-aliasingフラグにもかかわらず、ミスアライメントに加えて厳密なエイリアスに違反し、クラッシュします（OS XのGCC 7.1.0でテスト済み）。



デバッグ： UBSanはミスアライメントを検出できます。



軽減策：不明



結論： UBSanを使用する

I / Oも実行も終了しないループ

説明： IまたはOを実行せず、完了しないCまたはC ++コードのループは、未定義であり、コンパイラーによって任意に終了できます。 この記事とこのメモを 参照してください 。



デバッグ：ツールなし



軽減策：いいえ。ただし、コンパイラーを過度に最適化することを避けます。



結論：このUBは実用的な問題ではありません（たとえ私たちにとって不快な場合でも）。

データの競合

説明：データの競合は、メモリの一部が複数のスレッドからアクセス可能であり、そのうちの少なくとも1つが記録に使用可能であり、ロックなどのメカニズムによってアクセスが同期されていない場合に発生します。 データコンテストは、CおよびC ++の最新バージョンでUBにつながります（これらの標準はマルチスレッドコードを記述していないため、古いバージョンでは意味がありません）。





説明： TSanは、動的メモリコンテストの優れた検出機能です。 Valgrind用のHelgrindプラグインなど、同様のツールは他にもありますが、最近は使用していません。 動的な競合検出器の使用は、競合が機能するのが非常に難しいという事実によって複雑になり、最悪の部分は、それらの動作がコアの数、フロースケジューラアルゴリズム、テストマシンで実行中のもの、ムーンフェイズなどに依存することです



軽減策：スレッドを作成しない



結論：この特定のUBには良いアイデアがあります。ロックオブジェクトが気に入らない場合は、並行して実行されるコードを使用せず、代わりにアトミックアクションを使用します。

シーケンスなしの変更

説明： Cでは、「フォローポイント」は、x ++などの副作用のある式が有効になるタイミングを遅らせます。 C ++には、このルールとは異なるものの、ほぼ同等の言い回しがあります。 どちらの言語でも、シーケンスポイントに違反する変更はUBにつながります。



デバッグ：一部のコンパイラは、次の規則に明らかな違反がある場合に警告を生成します。

 $ cat unsequenced2.c int a; int foo(void) { return a++ - a++; } $ clang -c unsequenced2.c unsequenced2.c:4:11: warning: multiple unsequenced modifications to 'a' [-Wunsequenced] return a++ - a++; ^ ~~ 1 warning generated. $ gcc-7 -c unsequenced2.c -Wall unsequenced2.c: In function 'foo': unsequenced2.c:4:11: warning: operation on 'a' may be undefined [-Wsequence-point] return a++ - a++; ~^~
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、小さな間接違反は警告を引き起こしません。

 $ cat unsequenced.c #include <stdio.h> int main(void) { int z = 0, *p = &z; *p += z++; printf("%d\n", z); return 0; } $ gcc-4.8 -Wall unsequenced.c ; ./a.out 0 $ gcc-7 -Wall unsequenced.c ; ./a.out 1 $ clang -Wall unsequenced.c ; ./a.out 1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

軽減策：不明ですが、副作用が実行される順序を決定するのはほとんど簡単です。 Java言語は、これがどのように行われるかの例です。 このような制限が現代の最適化コンパイラを妨げると信じていた困難な時期がありました。 標準化委員会が、そうではないと真剣に考えている場合、コンパイラ開発者は規則に従う必要があります。 理想的には、すべての主要なコンパイラーはそのような場合に同じことをすべきです。



結論：ある程度練習すれば、コーディング中にシーケンスポイントの潜在的な違反に気付くことはそれほど難しくありません。 副作用のある非常に複雑な式が表示されることを心配する必要があります。 これはレガシーコードで発生しますが、見た目はまだ動作します。つまり、これは問題ではないかもしれません。 実際、この問題はコンパイラで修正する必要があります。



シーケンスポイントの違反に関連する非UBは、コンパイラーによって指定された順序でステートメントを実行できる「不定シーケンス」です。 例は、f（a（）、b（））の計算で2つの関数が呼び出される順序です。 この順序も定義する必要があります。 たとえば、左から右へ。 完全にクレイジーな状況を考慮しない場合、速度の損失はありません。



継続する。