ぶら下がっているポインタ

コンピュータ プログラミングにおけるダングリング ポインターとワイルド ポインターは、適切な型の有効なオブジェクトを指していないポインターです。これらはメモリ安全性違反の特殊なケースです。より一般的には、ダングリング参照とワイルド参照は、有効な宛先に解決されない 参照です。

ダングリング ポインタは、オブジェクトの破棄中、つまり、入ってくる参照を持つオブジェクトがポインタの値を変更せずに削除または割り当て解除され、ポインタが割り当て解除されたメモリのメモリ位置を指し続けるときに発生します。システムは、以前に解放されたメモリを再割り当てすることがあり、プログラムが(現在の) ダングリング ポインタを逆参照すると、メモリにまったく異なるデータが含まれるようになるため、予期しない動作が発生する可能性があります。プログラムがダングリング ポインタによって参照されるメモリに書き込むと、無関係なデータが静かに破損し、見つけるのが非常に難しい微妙なバグが発生する可能性があります。メモリが別のプロセスに再割り当てされている場合、ダングリング ポインタを逆参照しようとすると、セグメンテーション エラー(UNIX、Linux) または一般保護違反(Windows) が発生する可能性があります。プログラムが、カーネルのメモリ アロケータによって使用されるブックキーピング データを上書きできる十分な権限を持っている場合、破損によってシステムが不安定になる可能性があります。ガベージ コレクションを備えたオブジェクト指向言語では、到達不能なオブジェクト、つまり入力ポインタを持たないオブジェクトを破棄するだけで、ぶら下がり参照が防止されます。これは、トレースまたは参照カウントによって保証されます。ただし、ファイナライザはオブジェクトへの新しい参照を作成する場合があり、ぶら下がり参照を防止するには オブジェクトの復活が必要になります。

ワイルドポインターは、初期化されていないポインターとも呼ばれ、ポインターが既知の状態に初期化される前に使用された場合に発生します。これは一部のプログラミング言語で発生する可能性があります。ワイルドポインターは、ダングリングポインターと同じ不規則な動作を示しますが、宣言された変数が初期化される前にアクセスすると多くのコンパイラーがコンパイル時に警告を出すため、検出されない可能性は低くなります。^[1]

多くの言語 (例: C プログラミング言語) では、オブジェクトをメモリから明示的に削除したり、戻り時にスタック フレームを破棄したりしても、関連付けられたポインタは変更されません。ポインタは、その場所が他の目的に使用されるようになったとしても、メモリ内の同じ場所を指し続けます。

簡単な例を以下に示します。

{ 
char * dp = NULL ; /* ... */ { char c ; dp = & c ; } /* c はスコープ外になります */ /* dp はダングリングポインタになります */ }      
   
   
        
         
    
     
     

オペレーティング システムが実行時にnull ポインターへの参照を検出できる場合、上記の問題の解決策は、内部ブロックが終了する直前に dp に 0 (null) を割り当てることです。別の解決策としては、何らかの方法で dp がさらに初期化されずに再び使用されないように保証することです。

malloc()ぶら下がりポインターのよくある原因として、 とライブラリ呼び出しの混在が挙げられますfree()。ポインターは、それが指すメモリ ブロックが解放されるとぶら下がりポインターになります。前の例と同様に、これを回避する 1 つの方法は、以下に示すように、参照を解放した後でポインターを必ず null にリセットすることです。

#include <stdlib.h> 

void func () { char * dp = malloc ( A_CONST ); /* ... */ free ( dp ); /* dp はダングリングポインタになります */ dp = NULL ; /* dp はダングリングではなくなりました */ /* ... */ } 

       
    
             
              
    

よくある間違いは、スタックに割り当てられたローカル変数のアドレスを返すことです。呼び出された関数が戻ると、これらの変数のスペースは割り当て解除され、技術的には「ガベージ値」になります。

int * func ( void ) { int num = 1234 ; /* ... */ return & num ; } 

       
    
     

を呼び出した後しばらくの間は、ポインタからの読み取りを試みると正しい値 (1234) が返される可能性がありますfuncが、その後に呼び出される関数によって、 に割り当てられたスタック ストレージがnum他の値で上書きされ、ポインタが正しく動作しなくなる可能性があります。 へのポインタをnum返す必要がある場合は、numは関数を超えたスコープを持つ必要があります。つまり、 として宣言できますstatic。

アントニ・クレツマール [pl] (1945–1996)は、ぶら下がり参照現象のない完全なオブジェクト管理システムを考案しました。^{[2]同様のアプローチは、フィッシャーとルブラン[3]によって}Locks-and-keysという名前で提案されました。

ワイルド ポインターは、最初に使用する前に必要な初期化を省略することによって作成されます。したがって、厳密に言えば、初期化を強制しないプログラミング言語のすべてのポインターは、ワイルド ポインターとして始まります。

これはほとんどの場合、初期化を省略したために発生するのではなく、初期化を飛び越えたために発生します。ほとんどのコンパイラはこれについて警告することができます。

int f ( int i ) { char * dp ; /* dp はワイルド ポインターです */ static char * scp ; /* scp はワイルド ポインターではありません:                         * 静的変数は開始時に 0 に初期化され、                        その後は最後の呼び出し                        からの値を保持します。 * コメントされていない場合                        、この機能の使用は悪い                        スタイルと見なされる可能性があります */ }  

         
        

バッファオーバーフローのバグと同様に、ダングリング/ワイルドポインタのバグは、セキュリティホールになることがよくあります。たとえば、ポインタを使用して仮想関数呼び出しを行うと、 vtableポインタが上書きされるため、別のアドレス (エクスプロイトコードを指す可能性があります) が呼び出される可能性があります。または、ポインタを使用してメモリに書き込むと、他のデータ構造が破損する可能性があります。ポインタがダングリングになった後にメモリが読み取られるだけでも、情報漏洩 (そこに割り当てられた次の構造に興味深いデータが格納された場合) や権限の昇格(無効になったメモリがセキュリティチェックで使用された場合) につながる可能性があります。ダングリングポインタが解放された後、新しいメモリチャンクを割り当てずに使用された場合、これは「解放後使用」脆弱性として知られています。^[4]たとえば、CVE - 2014-1776 は、Microsoft Internet Explorer 6 から 11 の解放後使用の脆弱性です^{[5] が、}高度な持続的脅威によるゼロデイ攻撃で使用されています。^[6]

C では、最も単純な手法は、ポインターのリセットを保証する関数 (または類似の関数) の代替バージョンを実装することですfree()。ただし、この手法では、ポインターのコピーを含む可能性のある他のポインター変数はクリアされません。

#include <assert.h> #include <stdlib.h> 
 

/* 'free()' の代替バージョン */ 
static void safefree ( void ** pp ) { /* デバッグ モードでは、pp が NULL の場合は中止します */ assert ( pp ); /* free(NULL) は正常に動作するため、デバッグ モードでは assert 以外のチェックは必要ありません */ free ( * pp ); /* チャンクを解放します。free(NULL) が有効であることに留意してください */ * pp = NULL ; /* 元のポインタをリセットします */ }   

    
    
    
                      
                       


int f ( int i ) { char * p = NULL , * p2 ; p = malloc ( 1000 ); /* チャンクを取得 */ p2 = p ; /* ポインターをコピー */ /* ここでチャンクを使用 */ safefree (( void ** ) & p ); /* 安全な解放。p2 変数には影響しません */ safefree (( void ** ) & p ); /* p が NULL にリセットされるため、この 2 番目の呼び出しは失敗しません */ char c = * p2 ; /* p2 はまだダングリング ポインターであるため、これは未定義の動作です。 */ return i + c ; }  

        
          
                    
    
            
            
              
       

代替バージョンは、 を呼び出す前に空のポインタの有効性を保証するためにも使用できますmalloc()。

safefree ( & p ); /* チャンクが解放されたかどうかは不明です */ p = malloc ( 1000 ); /* 今すぐ割り当てます */        
      

#defineこれらの使用は、便利なマクロ (一般的なものは#define XFREE(ptr) safefree((void **)&(ptr)))を作成するためのディレクティブによってマスクすることができ、メタ言語のようなものを作成したり、ツール ライブラリに個別に埋め込んだりすることができます。いずれの場合も、この手法を使用するプログラマーはfree()、 が使用されるすべてのインスタンスで安全なバージョンを使用する必要があります。そうしないと、再び問題が発生します。また、このソリューションは単一のプログラムまたはプロジェクトの範囲に限定されており、適切に文書化する必要があります。

より構造化されたソリューションの中で、C++ でダングリング ポインターを回避するための一般的な手法は、スマート ポインターを使用することです。スマート ポインターは通常、参照カウントを使用してオブジェクトを再利用します。その他の手法には、トゥームストーンメソッドやロック アンド キーメソッドなどがあります。^[3]

もう 1 つのアプローチは、 Boehm ガベージ コレクターを使用することです。これは、C およびC++の標準メモリ割り当て関数をガベージ コレクターに置き換える保守的なガベージ コレクターです。このアプローチでは、解放を無効にし、ガベージ コレクションによってオブジェクトを再利用することで、ダングリング ポインター エラーを完全に排除します。

Java のような言語では、メモリを明示的に解放するメカニズムがないため、ダングリング ポインタは発生しません。代わりに、ガベージ コレクターがメモリを解放することはありますが、これはオブジェクトがどの参照からもアクセスできなくなった場合に限られます。

Rust言語では、型システムが拡張され、変数の有効期間やリソースの取得の初期化も含まれるようになりました。言語の機能を無効にしない限り、ダングリング ポインタはコンパイル時に検出され、プログラミング エラーとして報告されます。

ダングリング ポインター エラーを明らかにするための一般的なプログラミング手法の 1 つは、ポインターが指しているストレージが解放されたら、ポインターをNULL ポインターまたは無効なアドレスに設定することです。NULL ポインターが逆参照されると (ほとんどの言語では)、プログラムは直ちに終了します。データの破損や予期しない動作が発生する可能性はありません。これにより、根本的なプログラミング エラーを見つけて解決しやすくなります。この手法は、ポインターのコピーが複数ある場合には役に立ちません。

一部のデバッガーは、解放されたデータを自動的に上書きして破棄します。通常は、特定のパターン0xDEADBEEF(たとえば、Microsoft の Visual C/C++ デバッガーは、解放された内容に応じて0xCC、0xCDまたは を使用します^[7] ) を使用します。これにより、データが役に立たなくなり、また非常に目立つようになるため、再利用されることが防止されます (パターンは、メモリがすでに解放されていることをプログラマーに示すのに役立ちます)。 0xDD

Polyspace、TotalView、Valgrind、Mudflap、^[8] AddressSanitizerなどのツールや、LLVM ^[9]をベースにしたツールも、ダングリングポインタの使用を検出するために使用できます。

その他のツール (SoftBound、Insure++、CheckPointer) は、ソース コードをインストルメント化して、ポインターの正当な値 (「メタデータ」) を収集および追跡し、各ポインター アクセスをメタデータに対して有効性をチェックします。

少数のクラスが疑われる場合の別の戦略は、そのクラスのすべてのメンバー関数を一時的に仮想 にすることです。クラス インスタンスが破棄/解放された後、仮想メソッド テーブルへのポインターが に設定されNULL、メンバー関数を呼び出すとプログラムがクラッシュし、デバッガーに問題のあるコードが表示されます。

• 一般的な脆弱性と露出
• リンクの腐敗
• メモリデバッガー
• 野生の枝