Process Control

将程序控制转移到不可信赖的应用程序、事务或是不可信赖的环境中，会导致应用程序以攻击者的名义执行恶意代码。

Process control 漏洞主要表现为以下两种形式：

— 攻击者能够篡改即将调用的程序的名称或事务的代码：攻击者直接地控制应用程序的名称和事务代码。

— 攻击者能够篡改调用程序或事务的环境：攻击者能够间接控制调用的程序或事务可用的通信区域。

在这种情况下，我们着重关注第一种情况，即攻击者有可能控制调用的程序名称或事务代码。这种类型的 Process Control 漏洞会在以下情况下出现：

1. 数据从不可信赖的数据源进入应用程序。



2. 数据作为代表调用的程序名称或事务代码的一个字符串或部分字符串使用。



3. 通过在调用的程序或事务中执行代码，应用程序授予攻击者在一般情况下无法获得的权限或能力。

示例 1：以下代码摘自具有特别权限的系统实用程序，它通过从 HTTP 请求中读取值来确定要调用的事务代码。

...
tid = request->get_form_field( 'tid' ).

CALL TRANSACTION tid USING bdcdata  MODE 'N'
                         MESSAGES INTO messtab.
...

以下摘录的代码使得攻击者能够调用任何事务，并有可能使用提升的应用程序权限来执行任意代码。因为程序不会检验从 HTTP 请求读取的值，所以如果攻击者可以控制这些值，他们就能欺骗应用程序去运行恶意代码，从而取得系统控制权。

从一个不可信赖的数据源或在不可信赖的环境中加载库或可执行文件，会导致应用程序以攻击者的名义执行恶意命令。

Process control 漏洞主要表现为以下两种形式：

- 攻击者可以篡改程序所加载的库或可执行文件的名称：攻击者直接控制库或可执行文件所使用的名称。

- 攻击者可以篡改加载库或可执行文件的环境：攻击者间接控制库或可执行文件名称的含义。

在这种情况下，我们着重关注第一种情况，即攻击者有可能控制加载的库的名称。这种类型的 Process Control 漏洞会在以下情况下出现：

1. 数据从不可信赖的数据源进入应用程序。



2. 数据将用作表示应用程序所加载的库或可执行文件的字符串或该字符串的一部分。



3. 通过在库或可执行文件中执行代码，应用程序授予攻击者在其他情况下无法获得的特权或能力。

示例 1：特权系统实用程序中的以下代码使用应用程序配置属性 APPHOME，然后根据指定目录的相对路径加载本地库。

  ...
  string lib = ConfigurationManager.AppSettings["APPHOME"];
  Environment.ExitCode = AppDomain.CurrentDomain.ExecuteAssembly(lib);
  ...

这段代码允许攻击者加载库或可执行文件，并通过修改应用程序配置属性 APPHOME 以指向包含恶意版本 LIBNAME 的不同路径，从而使用更高的应用程序权限来执行任意代码。由于程序不会验证从环境中读取的值，因此如果攻击者能够控制系统属性 APPHOME 的值，他们就能欺骗应用程序去运行恶意代码，从而控制系统。

从一个不可信赖的数据源或不可信赖的环境中加载库，会导致程序以攻击者的名义执行恶意代码。

Process control 漏洞主要表现为以下两种形式：

－ 攻击者能够篡改程序执行的库：攻击者直接控制了库的名称。

— 攻击者可以篡改库加载的环境：攻击者间接控制库名称的含义。

在这种情况下，我们着重关注第一种情况，即攻击者有可能控制加载的库的名称。这种类型的 Process Control 漏洞会在以下情况下出现：

1. 数据从不可信赖的数据源进入应用程序。

2. 数据作为字符串的一部分，代表一个由应用程序加载的库名。

3. 通过在库中执行代码，应用程序授予攻击者在一般情况下无法获得的权限或能力。

示例 1：以下代码来自于一个特权应用程序，使用注册表项来决定安装的目录，然后用基于指定目录的相对路径，加载一个库文件。

	...
	RegQueryValueEx(hkey, "APPHOME",
                      0, 0, (BYTE*)home, &size);
	char* lib=(char*)malloc(strlen(home)+strlen(INITLIB));
	if (lib) {
		strcpy(lib,home);
		strcat(lib,INITCMD);
		LoadLibrary(lib);
	}
	...

在这个例子中，代码通过篡改注册表主键来指定一个包含 INITLIB 恶意版本的其他路径，进而允许攻击者加载一个任意库，以提高的应用程序权限去执行库中的任意代码。因为程序不会校验从环境中读取的值，如果攻击者能够控制 APPHOME 的值，就能欺骗应用程序去运行恶意的代码。

示例 2：以下代码来自于一个基于 web 的管理实用程序，它允许用户访问一个接口，通过这个接口更新用户在系统上的配置文件。该实用程序使用一个名为 liberty.dll 的库，该库通常可在一个标准的系统目录中找到。

LoadLibrary("liberty.dll");

但是，程序并没有指定 liberty.dll 的绝对路径。在搜索顺序上，如果攻击者将一个名为 liberty.dll 的恶意库放在原本想要的库的前面，并且攻击者能够让程序在他们的环境（而不是 web 服务器环境）中运行，那么应用程序就会加载该恶意库，而不是原本想要的可信赖的库。由于这种类型的应用程序会以提高了的权限运行，因此攻击者的 liberty.dll 中的内容也将以提高的权限运行，这可能会使攻击者完全控制系统。

这种类型的攻击可能是由于在没有指明绝对路径的情况下，LoadLibrary() 所使用的搜索顺序造成的。如果当前目录比系统目录先搜索到，就像现在大多数最新的 Windows 版本，那么如果攻击者可在本地执行程序，这种类型的攻击就会变得十分简单。搜索顺序取决于操作系统的版本，在比较新的操作系统中，这一顺序由注册表主键控制：

HKLM\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode

该键值没有在 Windows 2000/NT 及 Windows Me/98/95 中定义。

在存在此键的操作系统上，LoadLibrary() 按以下方式运行：
如果 SafeDllSearchMode 为 1，搜索顺序如下所示：
（这是 Windows XP-SP1 及更高版本，包括 Windows Server 2003 的默认设置。）
1. 应用程序被加载的目录。
2. 系统目录。
3. 16 位系统目录（如果存在）。
4. Windows 目录。
5. 当前目录。
6. 在 PATH 环境变量中列出来的目录。
如果 SafeDllSearchMode 为 0，搜索顺序如下所示：
1. 应用程序被加载的目录。
2. 当前目录。
3. 系统目录。
4. 16 位系统目录（如果存在）。
5. Windows 目录。
6. 在 PATH 环境变量中列出来的目录。

将程序控制转移到不可信赖的应用程序或是不可信赖的环境中会导致应用程序以攻击者的名义执行恶意代码。

Process control 漏洞主要表现为以下两种形式：

— 攻击者能够篡改要调用的程序的名称：攻击者直接地控制应用程序的名称。

— 攻击者能够篡改调用程序的环境：攻击者能够间接控制调用的程序可用的通信区域。

在这种情况下，我们着重关注第一种情况，即攻击者有可能控制调用的程序名称。这种形式的进程控制漏洞在以下情况下发生：

1. 数据从不可信赖的数据源进入应用程序。



2.数据用作表示调用的程序的整个字符串或一部分，或者确定对调用程序的环境的某些控制。



3. 通过在调用的程序中执行代码，应用程序授予攻击者在一般情况下无法获得的权限或能力。

示例 1：以下来自具有特别权限的系统实用程序的代码从终端中读取值，以确定转移控制的目标程序的名称。

...
ACCEPT PROGNAME.
EXEC CICS
  LINK PROGRAM(PROGNAME)
  COMMAREA(COMA)
  LENGTH(LENA)
  DATALENGTH(LENI)
  SYSID('CONX')
END-EXEC.
...

此代码使攻击者能够将控制转移至一个程序，并有可能使用提升的应用程序权限来执行任意代码。因为程序不会检验从终端读取的值，所以如果攻击者可以控制这些值，他们就能欺骗应用程序，从而执行恶意代码并取得对系统的控制。

从一个不可信赖的数据源或是不可信赖的环境中加载库，会导致应用程序以攻击者的名义执行恶意代码。

Process control 漏洞主要表现为以下两种形式：

— 攻击者可以篡改程序加载的库的名称：攻击者直接地控制库所使用的名称。

— 攻击者可以篡改库加载的环境：攻击者间接控制库名称的含义。

在这种情况下，我们着重关注第一种情况，即攻击者有可能控制加载的库的名称。这种类型的 Process Control 漏洞会在以下情况下出现：

1. 数据从不可信赖的数据源进入应用程序。



2. 数据作为代表应用程序所加载的库的一个或部分字符串使用。



3. 通过在库中执行代码，应用程序授予攻击者在一般情况下无法获得的权限或能力。

示例 1：以下代码使用 Express 当前未记录的“功能”动态加载库文件。然后，Node.js 将继续在其正则库加载路径中搜索包含此库的文件或目录[1]。

var express = require('express');
var app = express();

app.get('/', function(req, res, next) {
  res.render('tutorial/' + req.params.page);
});

在 Express 中，传递到 Response.render() 的页面将加载先前未知的扩展库。这对于“foo.pug”等输入来说通常没有问题，因为这意味着加载 pug 库，该库是广为人知的模板引擎。但是，如果攻击者可以控制页面并进而控制扩展，那么他们便可以选择加载 Node.js 模块加载路径内的任何库。因为程序不会验证从 URL 参数接收的信息，所以攻击者可能会欺骗应用程序，去执行恶意代码并取得对系统的控制。

从一个不可信赖的数据源或是不可信赖的环境中加载库，会导致应用程序以攻击者的名义执行恶意代码。

Process control 漏洞主要表现为以下两种形式：

— 攻击者可以篡改程序加载的库的名称：攻击者直接地控制库所使用的名称。

— 攻击者可以篡改库加载的环境：攻击者间接控制库名称的含义。

在这种情况下，我们着重关注第一种情况，即攻击者有可能控制加载的库的名称。这种类型的 Process Control 漏洞会在以下情况下出现：

1. 数据从不可信赖的数据源进入应用程序。



2. 数据作为代表应用程序所加载的库的一个或部分字符串使用。



3. 通过在库中执行代码，应用程序授予攻击者在一般情况下无法获得的权限或能力。

例 1：以下代码来自于一个具有特别权限的系统实用程序，使用系统属性 APPHOME 来确定系统的安装目录，然后用基于指定目录的相对路径加载本地库。

	...
	$home = getenv("APPHOME");
	$lib = $home + $LIBNAME;
	dl($lib);
	...

这段代码允许攻击者加载库，并通过修改系统属性 APPHOME，指向一个包含恶意版本 LIBNAME 的不同路径，从而使用较高的应用程序权限去执行任意代码。由于程序不会验证从环境中读取的值，所以如果攻击者能够控制系统属性 APPHOME 的值，他们就能欺骗应用程序去运行恶意代码从而取得系统控制权。

例 2：下列代码使用 dl() 来从名为 sockets.dll 的库加载代码，此库可从多个位置加载，具体取决于您的安装和配置。

	...
	dl("sockets");
	...

这里的问题是，对于要加载的库来说，dl() 只会接受库的名称，而不接受库的路径。

在搜索顺序方面，如果攻击者将一份恶意的 sockets.dll 放在高于应用程序需要加载的文件的位置，那么应用程序就会加载该恶意代码，而不会选择加载最初需要的文件。由于应用程序的这一特性，它会以较高的权限运行，这就意味着攻击者的 sockets.dll 内容将以较高的权限运行，从而可能导致攻击者完全控制整个系统。

从一个不可信赖的数据源或是不可信赖的环境中加载库，会导致应用程序以攻击者的名义执行恶意代码。在 Ruby 中，存在可能会同时发生 Process Control 和 Command Injection 攻击的共同位置。

在 Ruby 中，当正在执行某个命令时通常会发生 Process Control 攻击，这使得会发生两个不同的攻击：

1. Process Control
Process Control 漏洞表现为以下两种形式：

— 攻击者可以篡改程序加载的库的名称：攻击者直接地控制库所使用的名称。

— 攻击者可以篡改库加载的环境：攻击者间接控制库名称的含义。

在这种情况下，我们着重关注第二种情况，即攻击者有可能通过程序加载指定库的恶意版本，以此来控制环境。

1. 攻击者为应用程序提供一个恶意的库。

2. 应用程序因为未指定一个绝对的路径，或未验证加载的文件而加载了恶意的库。

3. 通过在库中执行代码，应用程序授予攻击者在一般情况下无法获得的权限或能力。

请注意，当运行外部程序时，在 Windows 平台上可能会发生 Process Control 攻击，因为用于运行命令的 shell 是通过 RUBYSHELL 或 COMSPEC 环境变量选择的。如果攻击者能够在当前环境中修改这两个环境变量之一，这意味这两个环境变量所指的程序将使用权限或者运行的 Ruby 程序运行。

2. Command Injection
Command Injection 漏洞主要表现为以下两种形式：

－ 攻击者能够篡改程序执行的命令：攻击者直接控制了所执行的命令。

－ 攻击者能够篡改命令的执行环境：攻击者间接地控制了所执行的命令。

在这种情况下，我们着重关注第二种情况，即攻击者有可能通过篡改一个环境变量或预先在搜索路径中输入可执行的恶意内容，进而更改命令所代表的原始含义。这种类型的 Command Injection 漏洞会在以下情况下出现：

1. 攻击者篡改某一应用程序的环境。

2. 应用程序在没有指明绝对路径，或者没有检验所执行的二进制代码的情况下就执行命令。

3. 通过命令的执行，应用程序会授予攻击者一种原本不该拥有的特权或能力。

示例 1：以下代码通过运行 Kernel.system() 来运行称为 program.exe 的可执行文件，通常在标准系统目录中可找到该可执行文件。

...
system("program.exe")
...

这里的问题是双重的：
1. 在 Windows 平台上，Kernel.system() 通过 shell 执行程序。如果攻击者可以操纵 RUBYSHELL 或 COMSPEC 环境变量，这两个环境变量就能够指向恶意的可执行文件，通过为 Kernel.system() 指定的命令将会调用该可执行文件。由于应用程序自身的特性，它需要特定的权限执行系统操作，这意味着攻击者会利用这些权限执行自己的 program.exe，从而可能导致攻击者完全控制这个系统。
2. 这种情况下在所有平台上，问题在于，程序没有指定一个绝对的路径，并且在执行 Kernel.system() 调用之前未能清理其环境。如果攻击者能够篡改 $PATH 变量，使其指向一个名为 program.exe 的恶意二进制代码，然后在指定环境中运行应用程序，那么应用程序就会加载该恶意二进制代码，并以此替代原本期望的代码。由于应用程序自身的特性，它需要特定的权限执行系统操作，这意味着攻击者会利用这些权限执行自己的 program.exe，从而可能导致攻击者完全控制这个系统。