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 が原因で、プログラムは割り当てられたメモリの境界外にある値にアクセスします。

例: 次のコードはスタックから任意の値を読み取っています。これは、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 が原因で、プログラムはデータ値を不正に変換したり、割り当てられたメモリの境界外にある値にアクセスしたりしてしまう可能性があります。

例: 次のコードは、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
)
...