当同一内存地址被当作参数不止一次地调用 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 Return、Commenting-Out 和 Stretched String。
示例 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 错误等。有关 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 错误等。有关 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 指定的内部操作的能力。

示例 1：以下代码使用隐式内部 Intent。

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

Android Intents 用于通过提供有关给定组件执行的操作的指令将应用程序和应用程序组件绑定在一起。创建待定意图以便稍后传送 Intent。隐式意图有助于从任何给定的外部组件调用意图，使用通用名称和筛选器来确定执行。

当隐式 Intent 创建为 PendingIntent，这可能允许将 Intent 发送到在预期时间上下文之外运行的非预期组件，从而使系统容易受到拒绝服务、私人和系统信息泄露以及权限提升等攻击途径。

示例 1：以下代码使用隐式 PendingIntent。

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