セカンダリ リリースを簡単に理解すると、同じポインタが指すメモリが 2 回解放されることになります (C 言語のソース コードの場合、同じポインタが解放されます)。 free() 操作により、セカンダリ リリースが発生する可能性があります。この記事の第 3.1 章にある欠陥のあるコードは、この種の状況について説明しています。 C 言語では、不適切なシャロー コピー操作が二次リリースの一般的な原因の 1 つです。たとえば、代入演算子またはコピー コンストラクターを 1 回呼び出すと、2 つのオブジェクトのデータ メンバーが同じ動的メモリを指すようになります。このとき、参照カウントの仕組みが非常に重要になり、参照カウントが不適切でオブジェクトがスコープ外になった場合、デストラクタは二つのオブジェクトが共有するメモリを解放します。別のオブジェクトの対応するデータ メンバーは、解放されたメモリ アドレスをポイントします。このオブジェクトもスコープ外になると、そのデストラクターが再度メモリを解放しようとし、二次的な解放の問題が発生します。詳細については、「CWE ID 415: ダブル無料」を参照してください。
メモリの 2 回目のリリースは、アプリケーションのクラッシュ、サービス拒否攻撃、その他の問題を引き起こす可能性があります。これは一般的な脆弱性の 1 つです。 C/C 1 で。 2018 年 1 月から 11 月までに、CVE に関連する脆弱性情報は合計 38 件ありました。脆弱性の一部は次のとおりです。
概要 | |
---|---|
CVE-2018-17097 | |
CVE-2018-16425 | |
CVE-2018-16402 | |
3.1 欠陥コード
上記のコード例では、32 行目で malloc() が使用されています。
free() を使用して割り当てられたメモリを解放します。38 行目の
for ループ ステートメントでは、すでに解放されているメモリが解放されます。 ##data
は一度リリースされたため、二次リリースで問題が発生しました。 360 Code Guardを使用して上記のサンプルコードを検出すると、「セカンダリリリース」の不具合が検出でき、表示レベルは中です。図 1 に示すように:
上記の修復コードで、Samate によって指定された修復方法は次のとおりです。メモリ割り当てには 32 行目で
malloc() を使用し、36 行目では
を使用して解放すると、解放後にメモリは解放されません。 360 Code Guard を使用して修復されたコードを検出すると、「セカンダリ リリース」の欠陥がないことがわかります。図 2 に示すように:
図 2: 修復後の検出結果
二次リリースを回避するには、以下の点に注意する必要があります:
(1) ワイルドポインタは、二次リリースおよびリリース後の使用の重要な理由の 1 つです。ワイルド ポインタの有効性 方法は、ポインタを解放した直後にNULL
に設定するか、別の正当なオブジェクトを指すように設定することです。(2) C のシャロー コピーによって引き起こされるセカンダリ リリースの問題については、常にディープ コピーを実行することが良い解決策です。
(3) ソース コードの静的解析ツールを使用すると、プログラム内で考えられるセカンダリ リリースの問題を自動的に発見できます。
以上がC言語ソースコードの二次公開にはどのような危険性があるのでしょうか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。