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 的惡意程式庫，而這個程式庫在搜尋時的排名比真正想要的程式庫還要前面，並且還有方法可以讓程式在其環境中執行而不是在伺服器的環境中，那麼應用程式將會載入此惡意程式庫，而不是您想要的程式庫。因為這種類型的應用程式都有比較高的權限，因此攻擊者提供的 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 漏洞主要表現在以下兩種形式：

- 攻擊者可以篡改呼叫的程式名稱：攻擊者直接控制應用程式名稱。

- 攻擊者可以篡改呼叫的程式所在環境：攻擊者間接控制呼叫程式的可用通訊區域。

在此案例中，我們著重於第一種情況，即攻擊者可以控制叫用的程式名稱的可能性。此類型的 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 插入式攻擊。

在 Ruby 內，Process Control 通常會在執行指令時發生，導致兩種不同的攻擊：

1. Process Control
Process Control 弱點主要表現在以下兩種形式：

- 攻擊者可以篡改程式載入的程式庫名稱：攻擊者直接控制程式庫名稱。

- 攻擊者可以篡改程式庫載入的所在環境：攻擊者間接控制程式庫名稱代表的意義。

在此案例中，我們著重於第二種情況，即攻擊者有可能透過指定惡意的程式庫，藉此來控制環境的可能性。

1. 攻擊者向應用程式提供惡意的程式庫。

2. 應用程式因為未指定絕對路徑，或者未驗證載入的檔案而載入惡意的程式庫。

3. 藉由執行程式庫的程式碼，應用程式會給予攻擊者不應該擁有的權限或能力。

請注意，Process Control 可在執行外部程式時在 Windows 平台上發生，因為用於執行指令的 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 將會在這些權限下執行，攻擊者可能會完全控制系統。