Often Misused: File System(readlink)

ABSTRACT

readlink() 函數不以 “\0” 終止其輸出。

EXPLANATION

函數 readlink() 有三個參數： linkname, buffer, 和 buf_sz。該函數查找由符號鏈接 linkname 指向的文件名，并且把找到的名稱存儲在第二個參數 buffer 中。函數在把最多 buf_sz 字符存儲到 buffer 中。這個函數在 C 庫中不太常見，因為它不以 “\0” 來終止 buffer。而是返回它寫入的字符數量。

誤用 readlink() 的情形通常如下所示：


char buf[256];
len = readlink(lname, buf, sizeof(buf));
buf[len] = '\0';

如果 len 等于 sizeof(buf)，寫入 “\0” 終止符將會有一個字節超過 buf。

一個解決這個問題的簡單（但并不正確）方法是嘗試擴大 buf，使它的長度總能存放結果：


char buf[PATH_MAX+1];
len = readlink(lname, buf, sizeof(buf));
buf[len] = '\0';

但是這種“修復”錯誤地假設了 PATH_MAX 即代表了 file system 中文件的最長路徑。（PATH_MAX 只是界定了一次調用可以傳遞給內核的最長的相對路徑。）在大多數 Unix 和 Linux 系統上，想要判斷路徑的最大長度并不容易。因此 off-by-one 的 buffer overflow 風險依然存在。

撇開 Buffer overflow 不說，每當單個調用 readlink() 返回一個與傳遞至其第三個參數一樣的值時，程序是無法知道名稱中到底多出了多少字節，還是為避免溢出緩沖區已經將 readlink() 截短。

REFERENCES

[1] Standards Mapping - OWASP Top 10 2004 - (OWASP 2004) A5 Buffer Overflow

[2] Standards Mapping - Security Technical Implementation Guide Version 3 - (STIG 3) APP3590.1 CAT I

[3] Standards Mapping - Security Technical Implementation Guide Version 3.4 - (STIG 3.4) APP3590.1 CAT I

[4] Standards Mapping - Common Weakness Enumeration - (CWE) CWE ID 249, CWE ID 560

[5] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 - (PCI 1.2) Requirement 6.3.1.1

[6] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 - (PCI 2.0) Requirement 6.5.2

[7] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 - (PCI 1.1) Requirement 6.5.5

[8] The GNU C Library Reference Manual The GNU Software Foundation

这里只有精品视频