free() が同じメモリ アドレスを引数にして複数回コールされた場合、Double Free エラーが発生します。

free() を同じ値で 2 回コールすると、Buffer Overflow が発生する可能性があります。プログラムが free() を同じ引数で 2 回コールすると、プログラムのメモリ管理データ構造が破損します。これにより、プログラムがクラッシュするか、一部の環境では、その後に malloc() を 2 回コールして同じポインタを戻すことになります。malloc() が同じ値を 2 回戻し、その後に攻撃者が、この二重に割り当てられたメモリに書き込まれたデータの制御をプログラムから得た場合、プログラムは Buffer Overflow 攻撃に対して脆弱になります。

例 1: 次のコードは、Double Free の脆弱性が含まれる単純な例です。

	char* ptr = (char*)malloc (SIZE);
	...
	if (abrt) {
	  free(ptr);
	}
	...
	free(ptr);

Double Free の脆弱性のよくある原因には、次の 2 つがあります (この2 つが重なる場合もあります)。

- エラー条件などの例外的状況。

- プログラムのどの部分でメモリを解放するかに関して混乱が発生している。

Double Free 脆弱性には先ほどの例ほど複雑ではないものもありますが、大部分は数百の行や、場合によっては複数のファイルに分散しています。グローバル変数を複数回解放する誤りは特によく見られます。

Unicode 双方向オーバーライド制御文字を含むソース コードは、インサイダー脅威攻撃の兆候になる可能性があります。このような攻撃は、C、C++、C#、Go、Java、JavaScript、Python、Rust などのプログラミング言語のサプライ チェーンを利用して行われます。この攻撃の亜種のいくつかは、すでに Nicholas Boucher と Ross Anderson の両氏によって公開されています (Early Returns、Commenting-Out、および Stretched Strings)。
例 1: 次のコードは、C ソース コード ファイルにある制御文字を示しており、Early Return 攻撃につながります。

#include <stdio.h>

int main() {
	/* Nothing to see here; newline RLI /*/ return 0 ;
	printf("Do we get here?\n");
	return 0;
}

Example 1 の RLI (Right-to-Left Isolate) Unicode 双方向制御文字により、コードは次のように表示されます。

#include <stdio.h>

int main() {
	/* Nothing to see here; newline; return 0 /*/
	printf("Do we get here?\n");
	return 0;
}

特に注目すべきは、脆弱なエディター/ビューアーでコード レビューを実行する開発者は、脆弱なコンパイラーが何を処理するかを視覚的に確認できないことです。具体的には、プログラム フローを変更するアーリー リターン ステートメントです。

このライブラリは試験用です。作業の目的が不明な場合は、実運用環境で使用しないでください。

Buffer Overflow は、ソフトウェアセキュリティの脆弱性の中で最も有名な形態でしょう。Buffer Overflow の脆弱性については大半のソフトウェア開発者に知られているにも関わらず、依然として Buffer Overflow は新旧を問わずアプリケーションに対して最も多く見られる攻撃です。これは、Buffer Overflow には多種多様の発生形態があることや、この攻撃を阻止するために使用される手法が誤りやすいものであることによるものです。

古典的な Buffer Overflow の悪用では、攻撃者がプログラムに送信したデータが、それよりも小さいサイズのスタックバッファに格納されます。その結果、コールスタックにある情報、特に関数の戻りポインタが上書きされます。このデータがセットした戻りポインタの値に関数が戻ると、攻撃者のデータに含まれる悪意あるコードに制御が移ります。

このタイプのスタック Buffer Overflow は一部のプラットフォームや開発コミュニティでは今でも一般的ですが、ほかにもヒープ Buffer Overflow や「一つ違い」エラーなどのさまざまな Buffer Overflow があります。Buffer Overflow 攻撃の仕組みを解説した書籍には、Building Secure Software [1]、Writing Secure Code [2]、The Shellcoder's Handbook [3] など優れた本が数多くあります。

コードのレベルでは、Buffer Overflow 脆弱性には通常、プログラマの想定外のことが含まれます。C および C++ のメモリ操作関数の多くは境界チェックを行わないため、動作しているバッファに対して割り当てられた境界を簡単に超過する場合があります。strncpy() など境界が定められた関数の場合も、不正に使用されると脆弱性の原因になります。メモリの操作と、データのサイズや構成に関する誤った想定が同時に発生することが、大部分の Buffer Overflow の根本的な原因です。

この場合、不適切に構築されている Format String が原因で、プログラムは割り当てられたメモリの境界外にある値にアクセスします。

例 1: 次のコードはスタックから任意の値を読み取っています。これは、Format String にある形式指定子の数が、関数に渡される引数の数と一致していないためです。

void wrongNumberArgs(char *s, float f, int d) {
   char buf[1024];
   sprintf(buf, "Wrong number of %.512s");
}

Buffer Overflow は、ソフトウェアセキュリティの脆弱性の中で最も有名な形態でしょう。Buffer Overflow の脆弱性については大半のソフトウェア開発者に知られているにも関わらず、依然として Buffer Overflow は新旧を問わずアプリケーションに対して最も多く見られる攻撃です。これは、Buffer Overflow には多種多様の発生形態があることや、この攻撃を阻止するために使用される手法が誤りやすいものであることによるものです。

古典的な Buffer Overflow の悪用では、攻撃者がプログラムに送信したデータが、それよりも小さいサイズのスタックバッファに格納されます。その結果、コールスタックにある情報、特に関数の戻りポインタが上書きされます。このデータがセットした戻りポインタの値に関数が戻ると、攻撃者のデータに含まれる悪意あるコードに制御が移ります。

このタイプのスタック Buffer Overflow は一部のプラットフォームや開発コミュニティでは今でも一般的ですが、ほかにもヒープ Buffer Overflow や「一つ違い」エラーなどのさまざまな Buffer Overflow があります。Buffer Overflow 攻撃の仕組みを解説した書籍には、Building Secure Software [1]、Writing Secure Code [2]、The Shellcoder's Handbook [3] など優れた本が数多くあります。

コードのレベルでは、Buffer Overflow 脆弱性には通常、プログラマの想定外のことが含まれます。C および C++ のメモリ操作関数の多くは境界チェックを行わないため、動作しているバッファに対して割り当てられた境界を簡単に超過する場合があります。strncpy() など境界が定められた関数の場合も、不正に使用されると脆弱性の原因になります。メモリの操作と、データのサイズや構成に関する誤った想定が同時に発生することが、大部分の Buffer Overflow の根本的な原因です。

この場合、不適切に構築されている Format String が原因で、プログラムはデータ値を不正に変換したり、割り当てられたメモリの境界外にある値にアクセスしたりしてしまう可能性があります。

例 1: 次のコードは、Format String にある形式指定子 %d を使用して、浮動小数点数から f を不正に変換しています。

void ArgTypeMismatch(float f, int d, char *s, wchar *ws) {
   char buf[1024];
   sprintf(buf, "Wrong type of %d", f);
   ...
}

内部 Intent は、内部コンポーネントによって定義されたカスタム アクションを使用します。暗黙的なインテントを使用すると、特定のコンポーネントを知らなくても、外部コンポーネントからのインテントの呼び出しが容易になります。この 2 つを組み合わせることで、アプリケーションは、目的のアプリケーション コンテキストの外部から、特定の内部使用のために指定されたインテントにアクセスできるようになります。

外部アプリケーションから内部 Intent を処理できることにより、情報漏洩や Denial of Service からリモート コード実行に至るまで、Intent で指定された内部アクションのキャパシティに応じて、さまざまな深刻度の中間者攻撃が可能になります。

例 1: 次のコードは、暗黙的な内部 Intent を使用しています。

...
val imp_internal_intent_action = Intent("INTERNAL_ACTION_HERE")
startActivity(imp_internal_intent_action)
...

Android インテントは、特定のコンポーネントが実行するアクションについての指示を提供することにより、アプリケーションとアプリケーション コンポーネントをバインドするために使用されます。ペンディング インテントは、後で Intent を提供するために作成されます。暗黙的インテントは、一般的な名前やフィルタを使用して実行を決定することで、外部コンポーネントからのインテントの呼び出しを容易にします。

暗黙的な Intent が PendingIntent として作成されると、Intent が、想定される一時的なコンテキスト外で実行されている、意図しないコンポーネントに送信される可能性があります。その結果、システムが、Denial of Service、個人情報やシステム情報の漏洩、特権昇格などの攻撃にさらされることになります。

例 1: 次のコードは、暗黙的な PendingIntent を使用しています。

...
val imp_intent = Intent()
val flag_mut = PendingIntent.FLAG_MUTABLE
val pi_flagmutable_impintintent = PendingIntent.getService(
    this,
    0,
    imp_intent,
    flag_mut
)
...

PendingIntent の基盤となる Intent の変更を、作成後に許可すると、システムが攻撃にさらされやすくなります。これは主に、基盤となる Intent の全体的な機能に依存します。ほとんどの場合、PendingIntent フラグを FLAG_IMMUTABLE に設定することが、潜在的な問題を防ぐためのベスト プラクティスです。

例 1: 以下には、フラグ値 FLAG_MUTABLE を使用して作成された PendingIntent が含まれています。

...
val intent_flag_mut = Intent(Intent.ACTION_GTALK_SERVICE_DISCONNECTED, Uri.EMPTY, this, DownloadService::class.java)
val flag_mut = PendingIntent.FLAG_MUTABLE

val pi_flagmutable = PendingIntent.getService(
    this,
    0,
    intent_flag_mut,
    flag_mut
)
...

Memory Leak には 2 つの一般的な原因があり、これらが重なっていることもあります。

- エラー条件などの例外的状況。

- プログラムのどの部分でメモリを解放するかに関して混乱が発生している。

大部分の Memory Leak は一般にソフトウェアの信頼性の問題をもたらします。しかし攻撃者が意図的に Memory Leak を引き起こせる場合、攻撃者は (プログラムをクラッシュさせて) Denial of Service 攻撃を仕掛けたり、メモリ不足により引き起こされるプログラムの予測不能な動作を利用したりすることができます [1]。

例 1: 次の C 関数では、read() のコールが予想バイト数を戻せない場合に、割り当てられているメモリのブロックが漏洩します。

  char* getBlock(int fd) {
  char* buf = (char*) malloc(BLOCK_SIZE);
  if (!buf) {
    return NULL;
  }
  if (read(fd, buf, BLOCK_SIZE) != BLOCK_SIZE) {
    return NULL;
  }
  return buf;
}

Memory Leak には 2 つの一般的な原因があり、これらが重なっていることもあります。

- エラー条件などの例外的状況。

- プログラムのどの部分でメモリを解放するかに関して混乱が発生している。

大部分の Memory Leak は一般にソフトウェアの信頼性の問題をもたらします。しかし攻撃者が意図的に Memory Leak を引き起こせる場合、攻撃者は (プログラムをクラッシュさせて) Denial of Service 攻撃を仕掛けたり、メモリ不足により引き起こされるプログラムの予測不能な動作を利用したりすることができます [1]。

例 1:realloc() のコールが元のメモリ割り当てのサイズ変更に失敗した場合に、次の C 関数は割り当てられているメモリブロックをリークしています。

char* getBlocks(int fd) {
  int amt;
  int request = BLOCK_SIZE;
  char* buf = (char*) malloc(BLOCK_SIZE + 1);
  if (!buf) {
    goto ERR;
  }
  amt = read(fd, buf, request);
  while ((amt % BLOCK_SIZE) != 0) {
     if (amt < request) {
        goto ERR;
     }
     request = request + BLOCK_SIZE;
     buf = realloc(buf, request);
     if (!buf) {
        goto ERR;
     }
     amt = read(fd, buf, request);
  }

  return buf;

  ERR:
  if (buf) {
    free(buf);
  }
  return NULL;
}

NULL ポインタエラーは通常、プログラマの想定が破られた結果として発生します。

NULL ポインタの問題点の大半は一般にソフトウェアの信頼性の問題をもたらします。しかし、攻撃者が意図的に NULL ポインタ間接参照を引き起こせる場合、その結果生じた例外を利用してセキュリティ ロジックを回避したり、アプリケーションにデバッグ情報を開示させてそれ以降の攻撃に役立てたりすることができます。

例 1: 次のコードでは、プログラマは、システムに常に「cmd」という名前の定義されたプロパティがあると前提しています。攻撃者がプログラムの環境を制御して「cmd」を未定義にできる場合、プログラムが trim() メソッドのコールを試みると NULL ポインタ例外が発生します。

String val = null;
...
cmd = System.getProperty("cmd");
if (cmd)
	val = util.translateCommand(cmd);
...
cmd = val.trim();

プログラミング言語の進化に伴い、以下の理由でメソッドが廃止されることがあります。

- 言語の進歩
- 操作の効率的で安全な実行方法に関する
理解の向上
- 特定の操作について定めた規則の変更

ある言語から削除されたメソッドは通常、より優れていると思われる別の方法で同じタスクを実行する新しいメソッドに置き換えられます。
例 1: 次のコードは、各 16 ビット Unicode 文字の最初の 8 ビットを指定する値とバイトの配列からストリング オブジェクトを構築します。

...
String name = new String(nameBytes, highByte);
...

この例では、nameBytes で表される文字列のエンコードにどの文字セットが使用されているかによって、コンストラクターがバイトを文字に正しく変換できない可能性があります。文字列のエンコードに使用される文字セットの進化により、このコンストラクターは非推奨となり、パラメーターの 1 つとして、変換のためにバイトをエンコードするために使用される、charset という名前のパラメーターを受け入れるコンストラクターに置き換えられました。

すべての関数がセキュリティリスクを招くという理由で廃止されたり、置き換えられたりするわけではありません。しかし多くの場合、廃止された関数があることは、その周辺のコードが無視されており、メンテナンスされていない状態であることを示します。ソフトウェアセキュリティは長い間、優先事項どころか検討事項ですらありませんでした。廃止予定または廃止済みの関数がプログラムで使用されていると、その周辺にセキュリティ上の問題がある可能性が浮上します。

関数の IsBadXXXPtr() クラスを使用すべきではない理由は多数あります。これらの関数には次のような特徴があります。
1) スレッドセーフではない。
2) 無効なメモリアドレスをプローブしたことによって引き起こされたクラッシュに関与していることが多い。
3) 例外状態の発生中に適切なエラー処理ができると勘違いされている。

例 1: 次のコードでは、不正なメモリ書き込みを防止するために IsBadWritePtr() が使用されています。

if (IsBadWritePtr(ptr, length))
{
    [handle error]
}

多くの場合、プログラマは例外を検出しようとしてこれらの関数を使用しますが、実際には修正する問題よりも多くの問題の原因となっています。

同じ名前のメンバーフィールドとメソッドが存在していると混乱します。フィールドにアクセスする、またはその逆の場合に、プログラマが誤ってメソッドをコールしやすくなります。

例 1:

public class Totaller {
  private int total;
  public int total() {
    ...
  }
}

Java での同期化は注意が必要です。Empty Synchronized Block は、プログラマが同期化に苦労して目的を達していないことを示していることが多くあります。

例 1:

synchronized(this) { }

Java Language Specification の 3.8 節では、機械的に生成されるソースコードのみに使用される識別子にドル ($) サインを限定しています。

例 1:

int un$afe;

この変数の最初の値は使用されません。初期化後は、変数には別の値が割り当てられるか、スコープ外に移ります。

例 1: 次のコード引用では、変数 r に割り当ててから、それを使用することなく、値を上書きしています。

  int r = getNum();
  r = getNewNum(buf);

この変数の値は使用されません。値が割り当てられた後は、変数には別の値が割り当てられるか、スコープ外に移ります。

例 1: 次のコード引用では、変数 r に割り当ててから、それを使用することなく、値を上書きしています。

  r = getName();
  r = getNewBuffer(buf);

この変数は一度も使用されません。変数は単に痕跡として残っているだけですが、使用されていない変数がバグを指摘している可能性もあります。

例 1: 次のコードでは、コピーアンドペーストのエラーによって、2 回使用されている同じループの繰り返し (i) が引き起こされています。変数 j は一度も使用されません。

  int i,j;

  for (i=0; i < outer; i++) {
    for (i=0; i < inner; i++) {
      ...

このカテゴリの関数は、オペレーティングシステムにより、また場合によってはオペレーティングシステムのバージョンによっても動作が変わります。実装の相違には、以下のものがあります。

- パラメーターの解釈方法のわずかな相違。結果の不整合をもたらします。

- 関数の一部の実装。深刻なセキュリティリスクをもたらします。

- 関数が定義されていないプラットフォームがある可能性。