C言語ソースコードの二次公開にはどのような危険性があるのでしょうか?

1. セカンダリ リリース

セカンダリ リリースを簡単に理解すると、同じポインタが指すメモリが 2 回解放されることになります (C 言語のソース コードの場合、同じポインタが解放されます)。 free() 操作により、セカンダリ リリースが発生する可能性があります。この記事の第 3.1 章にある欠陥のあるコードは、この種の状況について説明しています。 C 言語では、不適切なシャロー コピー操作が二次リリースの一般的な原因の 1 つです。たとえば、代入演算子またはコピー コンストラクターを 1 回呼び出すと、2 つのオブジェクトのデータ メンバーが同じ動的メモリを指すようになります。このとき、参照カウントの仕組みが非常に重要になり、参照カウントが不適切でオブジェクトがスコープ外になった場合、デストラクタは二つのオブジェクトが共有するメモリを解放します。別のオブジェクトの対応するデータ メンバーは、解放されたメモリ アドレスをポイントします。このオブジェクトもスコープ外になると、そのデストラクターが再度メモリを解放しようとし、二次的な解放の問題が発生します。詳細については、「CWE ID 415: ダブル無料」を参照してください。

2. セカンダリ リリースの害

メモリの 2 回目のリリースは、アプリケーションのクラッシュ、サービス拒否攻撃、その他の問題を引き起こす可能性があります。これは一般的な脆弱性の 1 つです。 C/C 1 で。 2018 年 1 月から 11 月までに、CVE に関連する脆弱性情報は合計 38 件ありました。脆弱性の一部は次のとおりです。

##CVE 番号##CVE-2018-18751GNU gettext バージョン 0.19.8 の read-catalog.c ファイルの「defaultaddmessage」関数には、二次的な無料の脆弱性があります。 CVE-2018-17097Olli Parviainen SoundTouch バージョン 2.0 には、WavFile.cpp ファイルの WavFileBase クラスにセキュリティの脆弱性があります。リモートの攻撃者がこの脆弱性を悪用する可能性があります。サービス拒否を引き起こすサービス (セカンダリ リリース)。 CVE-2018-16425OpenSC 0.19.0-rc1 より前のバージョンの libopensc/pkcs15-sc-hsm.c ファイルの「scpkcs15emuschsminit」関数が存在します脆弱性を 2 回リリースします。攻撃者はこの脆弱性を悪用し、特別に細工されたスマート カードを使用してサービス妨害 (アプリケーションのクラッシュ) を引き起こす可能性があります。 CVE-2018-16402elfutils バージョン 0.173 の libelf/elf_end.c ファイルにはセキュリティの問題があります。リモート攻撃者がこの脆弱性を悪用して拒否を引き起こす可能性があります。サービスの停止 (2) リリースとアプリケーションのクラッシュ)。 3. サンプル コード

概要

この例は、Samate Juliet Test Suite for C/C v1.3 (https:/) からのものです。 /samate.nist.gov/SARD/testsuite.php)、ソースファイル名: CWE415_Double_Free__malloc_free_char_17.c。

3.1 欠陥コード

上記のコード例では、32 行目で malloc() が使用されています。

メモリ割り当てを実行し、36 行目の

free() を使用して割り当てられたメモリを解放します。38 行目の for ループ ステートメントでは、すでに解放されているメモリが解放されます。 ##data は一度リリースされたため、二次リリースで問題が発生しました。 360 Code Guardを使用して上記のサンプルコードを検出すると、「セカンダリリリース」の不具合が検出でき、表示レベルは中です。図 1 に示すように:

図 1: セカンダリ リリース検出の例

3.2 修復コード

上記の修復コードで、Samate によって指定された修復方法は次のとおりです。メモリ割り当てには 32 行目で
malloc() を使用し、36 行目では

を使用します。 free()

を使用して解放すると、解放後にメモリは解放されません。 360 Code Guard を使用して修復されたコードを検出すると、「セカンダリ リリース」の欠陥がないことがわかります。図 2 に示すように:

図 2: 修復後の検出結果

4. 二次リリースを回避する方法

二次リリースを回避するには、以下の点に注意する必要があります:

(1) ワイルドポインタは、二次リリースおよびリリース後の使用の重要な理由の 1 つです。ワイルド ポインタの有効性 方法は、ポインタを解放した直後に

NULL

に設定するか、別の正当なオブジェクトを指すように設定することです。

(2) C のシャロー コピーによって引き起こされるセカンダリ リリースの問題については、常にディープ コピーを実行することが良い解決策です。 (3) ソース コードの静的解析ツールを使用すると、プログラム内で考えられるセカンダリ リリースの問題を自動的に発見できます。

以上がC言語ソースコードの二次公開にはどのような危険性があるのでしょうか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。