CWE-843: Access of Resource Using Incompatible Type (使用不相容類型通路資源)

ID: 843 類型：基礎 結構：簡單

狀态：未完成

描述

程式使用一種類型配置設定或初始化資源，例如指針、對象或變量，但稍後它使用與原始類型不相容的類型通路該資源。

擴充描述

當程式使用不相容的類型通路資源時，這可能會觸發邏輯錯誤，因為資源沒有預期的屬性。在沒有記憶體安全的情況下，如C和C++，類型混淆可能導緻越界記憶體通路。             

雖然在C中解析具有許多不同嵌入對象類型的資料時，這種弱點經常與聯合有關，但它可以出現在任何能夠以多種方式解釋相同變量或記憶體位置的應用程式中。

這種弱點并不是C和C++獨有的。例如，當需要scalar時，可以通過提供數組參數來觸發PHP應用程式中的錯誤，反之亦然。諸如Perl這樣的語言，當通路某個類型的變量時，它會像通路另一個類型一樣執行自動轉換，也可能包含這些問題。

相關視圖

 "研究概念" 視圖(CWE-1000)

Nature	Type	ID	Name
ChildOf	704	Incorrect Type Conversion or Cast
CanPrecede	119	Improper Restriction of Operations within the Bounds of a Memory Buffer

 "開發概念"視圖 (CWE-699)

Nature	Type	ID	Name
ChildOf

引入模式

階段	說明
實作

應用平台

語言

C (出現的可能性不确定)

C++ (出現的可能性不确定)

示例

例1

以下代碼使用聯合來支援不同類型消息的表示。它根據消息的類型對消息進行不同的格式設定。

(問題代碼)

Example Language: C 

#define NAME_TYPE 1

#define ID_TYPE 2

struct MessageBuffer

{

int msgType;

union {

char *name;

int nameID;

};

};

int main (int argc, char **argv) {

struct MessageBuffer buf;

char *defaultMessage = "Hello World";

buf.msgType = NAME_TYPE;

buf.name = defaultMessage;

printf("Pointer of buf.name is %p\n", buf.name);

buf.nameID = (int)(defaultMessage + 1);

printf("Pointer of buf.name is now %p\n", buf.name);

if (buf.msgType == NAME_TYPE) {

printf("Message: %s\n", buf.name);

}

else {

printf("Message: Use ID %d\n", buf.nameID);

}

}

代碼打算将消息作為名稱類型處理，并将預設消息設定為“hello world”。但是，由于buf.name和buf.nameid都是同一聯合的一部分，是以它們可以作為同一記憶體位置的别名，具體取決于編譯後的記憶體布局。             

是以，修改buf.nameid（int）可以有效地修改存儲在buf.name（字元串）中的指針。

程式的執行可能會生成如下輸出：             

名稱指針為10830             

指針現在是10831             

資訊：Ello World

注意buf.name的指針是如何更改的，即使buf.name沒有被顯式修改。              在這種情況下，省略消息的第一個“h”字元。但是，如果攻擊者能夠完全控制buf.nameid的值，那麼buf.name可能包含任意指針，導緻讀取或寫入超出界限。例2

下面的PHP代碼接受一個值，加5，然後列印和.

(問題代碼)

Example Language: PHP 

$value = $_GET['value'];

$sum = $value + 5;

echo "value parameter is '$value'<p>";

echo "SUM is $sum";

調用時輸入下面的查詢字元串時:

value=123

程式計算sum并且列印:

SUM is 128

然而，攻擊者可能提供下面的查詢串 :

value[]=123

用"[]" 标記的 $value 被作為數組對待,當計算sum時會産生緻命錯誤:

Fatal error: Unsupported operand types in program.php on line 2

例3

下面的Perl代碼旨在通過通路$userprivilegarray引用來查找使用者ID在0和3之間的特權。預期隻有userid 3是管理者（因為它列在數組的第三個元素中）.

(問題代碼)

Example Language: Perl 

my $UserPrivilegeArray = ["user", "user", "admin", "user"];

my $userID = get_current_user_ID();

if ($UserPrivilegeArray eq "user") {

print "Regular user!\n";

}

else {

print "Admin!\n";

}

print "\$UserPrivilegeArray = $UserPrivilegeArray\n";

在這種情況下，程式員打算使用“$userprivilegarray->$userid”通路數組中的正确位置。但由于省略了下标，“user”字元串與$userprivilegarray引用的标量表示形式進行了比較，後者的形式可能是“array（0x229e8）”或類似的形式。             

由于邏輯也“打開失敗”（CWE-636），是以該錯誤的結果是所有使用者都被配置設定了管理者權限。

雖然這是一個強制示例，但它示範了類型混淆如何産生安全後果，即使是在記憶體安全語言中。

種屬

關系	類型	ID	名稱
屬于	1157	SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)

說明

應用平台

這種弱點在任何類型的不安全程式設計語言中都是可能的。

研究空白

類型混淆的弱點受到了應用研究人員和主要軟體供應商對C和C++代碼的關注。一些公開報告的漏洞可能具有類型混淆作為根本原因的弱點，但這些漏洞可能被描述為“記憶體損壞”。這一弱點在未來幾年可能會變得突出。             

就其他語言而言，很少有關于類型混淆弱點的公開報告。這些可能是研究不足的。由于許多程式直接或間接地依賴于松散類型，潛在的“類型混淆”行為可能是有意的，可能需要更多的手動分析。