當不止一次地在同一個記憶體位址將 free() 做為一個引數來呼叫，就會出現 double free (釋放相同的記憶體空間兩次) 錯誤。



以相同值呼叫 free() 兩次，會導致 Buffer overflow。當程式使用相同引數呼叫 free() 兩次，就會毀損程式中的記憶體管理資料結構。這樣的毀損會使程式當機，或者在某些情況下，還會導致之後兩次的 malloc() 呼叫回傳相同的指標。如果 malloc() 兩次回傳值都相同，且程式之後讓攻擊者控制整個已經寫入雙倍分配記憶體的資料，此程式就變得容易受到 Buffer overflow 攻擊。

範例 1：以下程式碼顯示關於 double free (釋放相同的記憶體空間兩次) 弱點的簡單範例。

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

Double free 弱點的產生有兩個常見的原因 (有時候這兩個原因會同時出現)：

- 錯誤條件以及其他異常情況。

- 對於程式中負責釋放記憶體的部分混淆了。

雖然某些 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) Unicode 雙向控制字元導致程式碼被視為以下內容：

#include <stdio.h>

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

需要特別注意的是，開發人員在易受攻擊的編輯器/檢視器中執行程式碼檢閱時，不會明顯看到易受攻擊的編譯器將處理的內容。特別是修改程序流程的 early return 陳述式。

這個程式庫被視為實驗性，在您瞭解所從事為何之後才可將其用於生產環境。

Buffer overflow 可能是軟體安全性弱點最為人知的一種形式。大部分軟體開發人員都知道什麼是 Buffer overflow 弱點，但傳統和新開發的應用程式仍常遭到 Buffer overflow 攻擊。此問題的部份原因是，發生 Buffer overflow 的方式很多，部分原因是人們常常用不恰當的方式來防範 Buffer overflow。

在典型的 Buffer overflow 攻擊中，攻擊者會將資料傳送到程式，而程式會將其儲存在一個較小的堆疊緩衝區內。結果就是呼叫這個堆疊的資訊超出了它的邊界，其中包括函數的回傳指標。該資料設定了回傳指標的值，當函數回傳時，會將控制傳送到攻擊者資料所包含的惡意程式碼。

這類型的堆疊 Buffer overflow 在一些平台和開發社群中仍然很常見，但卻還有多種其他類型的 Buffer overflow，包括堆積 Buffer overflow 和差一錯誤 (off-by-one-error) 等等。有許多優秀的著作提供了關於堆疊 Buffer overflow 如何攻擊的具體資訊，包括 Building Secure Software[1]、Writing Secure Code[2]和 The Shellcoder's Handbook[3]。

在程式碼層級，會發生 Buffer overflow 弱點通常是因為程式設計師的假設被推翻。C 和 C++ 中的很多記憶體處理函數都沒有執行邊界值檢查，並會輕易地超出操作中緩衝區被配置的邊界值。甚至如 strncpy() 的範圍函數，使用不正確時也會引起弱點。大多數 Buffer overflow 弱點的根本原因，都是緩衝區的處理，加上對資料的大小或組成假設錯誤。

在此案例中，錯誤建構的 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 和差一錯誤 (off-by-one-error) 等等。有許多優秀的著作提供了關於堆疊 Buffer overflow 如何攻擊的具體資訊，包括 Building Secure Software[1]、Writing Secure Code[2]和 The Shellcoder's Handbook[3]。

在程式碼層級，會發生 Buffer overflow 弱點通常是因為程式設計師的假設被推翻。C 和 C++ 中的很多記憶體處理函數都沒有執行邊界值檢查，並會輕易地超出操作中緩衝區被配置的邊界值。甚至如 strncpy() 的範圍函數，使用不正確時也會引起弱點。大多數 Buffer overflow 弱點的根本原因，都是緩衝區的處理，加上對資料的大小或組成假設錯誤。

在此案例中，錯誤建構的 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 使用內部元件定義的自訂動作。隱含 Intent 可以促進從任何指定外部元件呼叫 Intent，而無需了解特定元件。將兩者相結合，會允許應用程式從所需的應用程式內容外部存取指定給特定內部使用的 Intent。

從外部應用程式處理內部 Intent 的能力，可以引發從資訊洩漏、Denial of Service 到遠端程式碼執行等各種不同嚴重程度的 man-in-the-middle 攻擊，具體取決於 Intent 指定之內部動作的能力。

範例 1：以下程式碼使用內部隱含內部 Intent。

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

Android Intent 用於透過提供有關特定元件執行之動作的指令，將應用程式和應用程式元件繫結在一起。建立 Pending Intent 是為了稍後傳送 Intent。隱含 Intent 有助於從任何特定外部元件呼叫 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
)
...