檔案系統和檔案 API 安全性缺失指南

让-雅克-卢梭發表於2024-08-22
API

要確定攻擊者是否能夠讀取 ours/secret 檔案的內容，我們可以逐步分析以下情況：

檔案建立和所有權：

一個以 root 身份執行的系統守護程序建立了 ours/secret 檔案，檔案所有權為 root:wheel，許可權為 rwx------（700）。這意味著只有 root 使用者可以讀取、寫入和執行這個檔案。
POSIX ACL：

為攻擊者應用了 POSIX "read" 擴充套件 ACL（訪問控制列表）。這通常允許攻擊者讀取檔案，儘管檔案的許可權設定為不允許。
擴充套件屬性：

系統為檔案新增了擴充套件屬性 com.apple.quarantine。這個屬性用於標記從網際網路下載的檔案，但它不會影響檔案的許可權或 ACL。
守護程序寫入內容：

守護程序向 ours/secret 檔案中寫入了內容。
基於這些點：

許可權：檔案許可權 rwx------ 限制了只有 root 使用者可以訪問該檔案。
ACL：如果 ACL 允許攻擊者讀取，那麼儘管檔案的標準 UNIX 許可權不允許，攻擊者還是能夠讀取該檔案。
擴充套件屬性：com.apple.quarantine 屬性不會影響訪問控制或許可權。
結論：
如果 POSIX "read" 擴充套件 ACL 確實賦予了攻擊者讀取許可權，那麼攻擊者可以讀取 ours/secret 的內容。ACL 的設定會覆蓋預設的檔案許可權，只要 ACL 允許讀取，攻擊者就能夠訪問檔案內容。
讓我們逐一解答這些問題，以幫助更全面地理解情況：

  1. 掛載情況如何？

    • 目前我們不清楚 HFS+ 是如何掛載的。這需要檢查掛載點和選項。

  2. 是否啟用了 noowners 選項？

    • noowners 選項指的是在掛載檔案系統時是否忽略檔案的所有者資訊。如果啟用了該選項，檔案的所有者和許可權可能不會起作用。你可以透過 mount 命令檢視掛載選項，或檢查系統文件來確認。

  3. 我們可以開啟 noowners 嗎？

    • 如果 HFS+ 檔案系統允許，理論上可以透過重新掛載或調整掛載選項來啟用 noowners。具體步驟依賴於系統的配置和許可權。

  4. 我們是否有訪問備份映象的許可權？

    • 如果 HFS+ 檔案系統有備份映象（如某些虛擬磁碟映象），你需要確認是否有許可權訪問這些映象。通常需要管理員許可權來訪問或修改映象。

  5. ours 目錄上方是否有其他掛載？

    • 需要檢查是否有其他檔案系統掛載在 ours 目錄上方。這可以透過 mount 命令或檔案系統工具檢視掛載點來確認。

  6. secret 檔案是普通檔案，還是一般意義上的“檔案”？

    • 確認 secret 是否是一個常規檔案。可能需要檢查檔案的實際型別和屬性，以確定是否是一個真正的檔案或僅僅是一個佔位符或連結。

  7. ACL（訪問控制列表）情況如何？

    • 需要檢查檔案的 ACL 設定。ACL 可以是允許（allow）或拒絕（deny）。透過 ls -le 或 getfacl 命令（在某些系統上）可以檢視檔案的 ACL 設定。

  8. ACL 是允許還是拒絕？

    • 確定 ACL 的型別是允許還是拒絕。ACL 規則決定了對檔案的訪問許可權，允許 ACL 將給予訪問許可權，而拒絕 ACL 將阻止訪問。

  9. 檔案上是否有其他 ACL？

    • 確認檔案是否有其他的 ACL 設定。這可以透過檢視檔案的所有 ACL 條目來實現。

  10. 隔離擴充套件屬性的值是什麼？

    • 檢視檔案的 com.apple.quarantine 擴充套件屬性的值。這個屬性用於標記檔案的來源，如是否從網路下載，並可能影響系統對該檔案的處理。

回答這些問題將幫助你更好地理解檔案的訪問控制和安全設定，從而確定攻擊者是否能夠訪問 secret 檔案的內容。
在 HFS+ 檔案系統上的 macOS 系統中，假設我們有以下情況：

檔案建立在攻擊者使用者擁有的名為 ours 的目錄中。
檔案由以 root 身份執行的系統守護程序建立。
ours/secret 檔案建立時的許可權為 root:wheel，許可權為 rwx------。
為攻擊者建立了 POSIX "read" 擴充套件 ACL。
系統會新增一個名為 com.apple.quarantine 的擴充套件屬性。
守護程序會向檔案中寫入內容。
問題是：攻擊者是否可以讀取 secret 檔案的內容？

分析：

檔案許可權：

rwx------ 許可權表示只有檔案的所有者（即 root）能夠讀取、寫入和執行檔案。
POSIX ACL：

POSIX "read" 擴充套件 ACL 允許指定使用者讀取檔案。這意味著如果 ACL 設定允許攻擊者讀取，則攻擊者可以繞過預設許可權並訪問檔案內容。
擴充套件屬性：

com.apple.quarantine 擴充套件屬性用於標記檔案是否從網路下載，但它不會影響檔案的讀取許可權。
守護程序寫入內容：

檔案內容由守護程序寫入，但這不改變檔案的許可權設定。
結論：

如果 POSIX "read" 擴充套件 ACL 設定正確，並且允許攻擊者讀取 secret 檔案，則攻擊者可以讀取檔案的內容。擴充套件 ACL 可以覆蓋預設的檔案許可權，只要 ACL 賦予了讀取許可權，攻擊者就能夠訪問檔案內容。
這是一個複雜的安全問題，涉及許多細節和潛在的漏洞點。我們逐步解答這些問題：

為什麼這個問題不能回答？
掛載情況如何？

HFS+ 如何掛載？ 我們不知道 HFS+ 檔案系統是如何掛載的，這會影響檔案許可權和訪問控制。
noowners 是否啟用？ 如果啟用了 noowners，檔案的所有者和許可權可能會被忽略。
我們能否啟用 noowners？ 需要根據系統的配置來決定。
我們是否有訪問備份映象的許可權？ 如果有備份映象，可能會影響訪問控制。
ours 上方是否有其他掛載？ 需要檢查是否有其他檔案系統掛載在 ours 目錄上方。
secret 檔案是什麼型別？

secret 是普通檔案還是一般意義上的“檔案”？ 需要確認檔案的實際型別。
ACL（訪問控制列表）情況如何？

ACL 是允許還是拒絕？ 需要確定 ACL 是允許訪問還是拒絕訪問。
檔案上是否有其他 ACL？ 可能存在多個 ACL 條目。
隔離擴充套件屬性的值是什麼？

com.apple.quarantine 擴充套件屬性的值是什麼？ 這可能影響檔案的處理，但不影響訪問許可權。
如何建立 secret？
secret 的建立方式如何？
路徑是否由我們控制，還是固定的？ 需要知道檔案路徑是否可控。
open() 是否跟隨符號連結？ 符號連結可能導致意外的檔案訪問。
是否呼叫了 open()？ 需要確認檔案是否由 open() 建立。
umask 是否被尊重？ umask 可能影響檔案的預設許可權。
誰設定了許可權？（是否有 chmod() 呼叫？） 需要確認是否有 chmod() 呼叫來設定檔案許可權。
檔案建立和 ACL 應用之間是否有競爭？ 檔案建立和 ACL 應用之間可能存在時間競爭條件。
擴充套件屬性（隔離標誌）應用之間是否有競爭？ 需要確認是否存在競爭條件。
誰設定了擴充套件屬性？ 系統設定擴充套件屬性，可能有安全影響。
write() 是否安全？
write() 是否安全？

write() 是否寫入了剛開啟的檔案？ 需要確認是否存在 creat()/open() 競態條件。
是否可以使用 sudo？ 使用 sudo 可能繞過一些安全限制，但需要具體情況具體分析。
macOS 是否有 SIP 規則防止攻擊者？

是否有 SIP（System Integrity Protection）規則防止攻擊者？ SIP 規則可能會限制一些系統操作，但不能完全解決所有問題。
安全研究和開發者問題
檔案操作非常難以正確處理：檔案操作的複雜性使得安全研究和開發非常困難。
如果我們（安全研究人員）無法推理這些問題，普通開發者如何處理？ 這是一個重大問題，表明需要更多的工具和方法來幫助理解和處理檔案操作的安全性。
基本知識回顧
POSIX 標準檔案許可權（rwxrwxrwx）
POSIX 檔案 API（open、read、chmod、unlink、mkdir、rename 等）
檔案系統物件型別（檔案 / 目錄 / 符號連結 / 硬連結）
理解這些基本知識有助於更好地分析和解決檔案系統安全問題。

POSIX 標準檔案許可權

  • POSIX 標準檔案許可權（rwxrwxrwx）:

    • 這些許可權用於定義檔案的讀取（r）、寫入（w）和執行（x）許可權，適用於檔案所有者、檔案所屬組和其他使用者。
    • 例子：
      • rwxrwxrwx 表示所有使用者都有讀取、寫入和執行許可權。
      • rwx------ 表示只有檔案所有者有許可權，其他使用者沒有任何許可權。

  • 需要注意的內容:

    • SUID (Set User ID): 使得程式以檔案所有者的許可權執行。
    • SGID (Set Group ID): 使得程式以檔案所屬組的許可權執行，對目錄而言，還會繼承目錄的組所有權。
    • Sticky Bit: 使得只有檔案所有者才能刪除該檔案，通常用於 /tmp 目錄中。

POSIX 檔案 API

  • 主要 API:

    • open(): 開啟檔案。
    • read(): 從檔案中讀取資料。
    • chmod(): 修改檔案許可權。
    • unlink(): 刪除檔案。
    • mkdir(): 建立目錄。
    • rename(): 重新命名檔案或目錄。

  • 標準:

    • 定義在 IEEE Std 1003.1-2024 中。
    • POSIX 標準文件

  • 擴充套件:

    • 有些作業系統新增了額外的系統呼叫，例如：
      • renameat2() 在 Linux 中。
      • renameatx_np() 在 macOS 中。

  • 特性:

    • 防止路徑中任何位置的符號連結（symlink）。
    • 原子交換檔案 inode。
    • 有時 POSIX 標準系統呼叫會接受額外的非 POSIX 標誌，比如 Linux 中的 O_DIRECT。

  • 缺陷:

    • rename(src, dst): 無法阻止符號連結被跟隨。
    • open() 的 O_NOFOLLOW: 只防止解析路徑的最後一部分。

高階檔案系統知識

  • POSIX 擴充套件 ACL:

    • 允許更細粒度的許可權控制。
    • 可以設定允許或拒絕許可權。
    • 實現因作業系統而異，Linux ACL 和 BSD/macOS ACL 不同，影響了可移植性。

  • 檔案系統物件型別:

    • 檔案（regular file）、目錄（directory）、符號連結（symlink）、FIFO（管道）、塊裝置（block device）、字元裝置（character device）。

  • 檔案系統內部結構:

    • 對檔案系統的內部工作原理有深入瞭解是很重要的。

  • 檔案系統擴充套件屬性:

    • IEEE 1003.1e 草案 17: 一個被撤銷的 POSIX 標準，但仍被實現。
    • 擴充套件 ACL:
      • 在 macOS 上可以使用 file_inherit T 來繼承目錄的 ACL。
      • 擴充套件 ACL 使得在檔案移動時，許可權設定也會隨之變化。
      • 擴充套件 ACL 是一種“隱蔽”的許可權控制方式，不會透過傳統 POSIX 呼叫如 stat() 顯示。

總結

  • 檔案操作的複雜性:

    • 檔案操作非常複雜，涉及許可權控制、檔案系統型別和檔案系統內部結構。
    • 對於安全研究人員和開發者而言，理解這些細節至關重要，以避免潛在的安全漏洞。

  • 開發者和安全研究人員的挑戰:

    • 檔案操作的安全性需要深入理解作業系統和檔案系統的內部實現。
    • 對於具有高可移植性的 API 和安全特性的開發，理解這些內容是非常必要的。

  • 概念:

    • 硬連結是在同一個檔案系統內使用不同的名稱引用同一個檔案。它們不能跨檔案系統（與符號連結不同）。
    • 硬連結並不是檔案的克隆，而是同一個檔案在不同路徑下的兩個視角。
    • 多個硬連結可以指向一個 inode，但通常不能用於目錄。

  • 目錄中的硬連結:

    • “..” 是指向父目錄的硬連結。
    • 目錄中的硬連結:
      • 例如 /a/b T b 在目錄 a 中是指向 b 的硬連結。
    • 在理論上，目錄間的實際硬連結（例如 ./x/a/ 和 ./x/b/ 之間）是嚴格禁止的。

三層攻擊面

  1. API 層:

    • 使用者空間應用程式中的漏洞。
    • 例如：open() 的不安全實現。

  2. VFS 層:

    • 核心中的漏洞。
    • 例如：VFS 移除目錄時，即使 unlink() 被呼叫，也可能發生錯誤。

  3. FS 層:

    • 使用者空間或核心空間（取決於 FS 驅動程式的執行位置）。
    • 例如：FAT32 驅動程式可能在競爭條件下不必要地返回錯誤。

POSIX 相容性

  • 相容性問題:

    • Linux、FreeBSD 和 macOS 都不是完全 POSIX 相容。
    • 雖然非常接近，但某些 POSIX 標準未被完全實現或有不同的實現。

  • POSIX 的定義:

    • 在實際應用中，通常指的是 Windows 以外的所有系統。
    • WSL（Windows Subsystem for Linux）並不完全符合 POSIX 標準。

VFS（虛擬檔案系統）

  • 功能:

    • VFS 充當使用者和底層檔案系統驅動程式之間的翻譯層。
    • 處理快取、全域性檔案系統魔法（如 union mounts、資源叉、AppleDouble 處理、firmlinks 等）。

  • 翻譯問題:

    • 並非所有檔案系統都支援 VFS 需要的所有功能。
    • 例如：macOS 在 rmdir() 時會從空目錄中清除 AppleDouble 檔案，這在檔案系統支援擴充套件屬性時可能導致 ENOTEMPTY 錯誤。

FS 驅動程式攻擊面

  • 漏洞:

    • 檔案系統驅動程式的程式碼往往較舊、不夠智慧或有問題。
    • 例如：在 macOS 上，FAT32 捲上的符號連結被“模擬”成具有特殊大小和內容的普通檔案。

  • 攻擊向量:

    • 檔案系統驅動程式常常被設計為處理複雜的檔案格式，因此容易受到惡意影像的攻擊。
    • 可能建立不可能的結構，如硬連結目錄、無限目錄迴圈、具有 2 個硬連結但連結計數為 1 的檔案等。

路徑解析和競爭條件

  • 路徑型別:

    • 絕對路徑（如 /etc/passwd）和 相對路徑（如 ./hello.txt）。

  • 路徑解析:

    • 檔案系統的檢視可能是過時的，因此路徑解析可能會出現意外結果。

  • 競爭條件示例:

    • 當檔案系統檢視在不同程序間不一致時，可能會出現競爭條件。
    • 例如，移動目錄時，路徑解析可能會失敗，導致意外的檔案訪問。

POSIX 檔案系統 API 的限制

  • 併發訪問:

    • POSIX 檔案系統 API 並未設計為處理併發訪問，尤其是在許可權邊界跨越時。

  • API 選擇問題:

    • open() 的 O_NOFOLLOW 只防止解析路徑的最後一個元件。
    • rename() 總是跟隨符號連結（儘管情況複雜）。

總結

  • 硬連結和檔案系統複雜性:

    • 硬連結的使用和檔案系統的設計有時會導致安全問題和複雜的攻擊面。
    • 對於安全研究人員和開發者，理解檔案系統的內部機制和潛在漏洞是至關重要的。

  • VFS 和 FS 驅動程式:

    • VFS 和 FS 驅動程式的設計和實現可能會引入複雜的攻擊向量，需要特別關注。

  • 路徑解析和競爭條件:

    • 路徑解析和檔案系統檢視的變化可能導致意外結果，需要謹慎處理併發操作。

訪問（access()）/開啟（open()）競爭條件

  • 經典的 TOCTOU（檢查時機與使用時機）:

    • 這是最經典的時間檢查與使用時間競爭條件（TOCTOU），其難以完全保護。
    • 硬連結和符號連結可能使這一問題更復雜。

  • 沒有 copy() 系統呼叫:

    • 每個程式必須實現自己的檔案複製例程，通常實現得不好。

  • 沒有遞迴 unlink() 或 rmdir():

    • 手動實現這些功能非常困難，容易出錯。
    • 這通常由庫提供，以避免重複程式碼。

  • 符號連結（symlinks）和臨時檔案（tempfiles）:

    • 符號連結和臨時檔案處理不當可能引發問題。
    • 檔案描述符名稱（如 stderr）被硬編碼，可能導致隱蔽的安全問題。

檔案系統擴充套件屬性

  • 擴充套件屬性（Extended Attributes）:

    • 大多數檔案系統支援額外的內容，例如擴充套件屬性和特殊掛載標誌。
    • 例如：
      • ext2/3/4: 支援 append-only、immutable、undeletable 檔案，覆蓋所有許可權檢查。
      • HFS+: 支援屬性、資源叉、壓縮等。

  • macOS 的資源叉:

    • macOS 的資源叉處理非常複雜。例如:
      $ rm a
$ echo hi > a
$ echo wat > a/..namedfork/rsrc
$ cat a/..namedfork/rsrc
wat
    • 這使得路徑查詢變得更加複雜。

特殊路徑標記和掛載點

  • 路徑標記:

    • 特殊標記（如 “..” 和 “/”）的含義不一致會導致多重解釋。
    • 例如：./a/..namedfork/rsrc 在 macOS 中表示檔案 a 的資源叉。

  • 掛載點:

    • 可以移動掛載點，如果能重新命名它們的父目錄。
    • 同一個磁碟可以多次掛載（Linux 支援，但 macOS 不支援）。

  • 聯合（union）和覆蓋（overlay）掛載:

    • 在 macOS 和 Linux 中，聯合掛載和覆蓋掛載允許在檔案未找到時查詢其他檔案系統。

macOS 的特性和漏洞

  • 特殊檔案系統行為:

    • .vol/ 支援透過 fsid 和 inodenum 訪問檔案：
      $ stat /etc/passwd
16777225 40077649 -rw-r--r-- 1 root wheel ...
$ stat /.vol/16777225/40077649
16777225 40077649 -rw-r--r-- 1 root wheel ...

  • 掛載和檔案系統屬性:

    • AppleSingle/AppleDouble 檔案：只有 AppleDouble 相關。
    • 檔案系統不支援 xattrs 時，macOS 會模擬這些屬性。

檔案系統漏洞和建議

  • 檔案系統驅動程式的攻擊面:

    • 檔案系統驅動程式常常對惡意影像非常敏感，因為它們大多隻是複雜的檔案格式解析器。

  • 使用者提供的名稱到核心表示的 inode 的處理:

    • 兩種路徑型別：絕對路徑和相對路徑。路徑解析可能非常直觀，且路徑的實際檢視可能過時。

學習資源

  • 手冊頁（man pages）:

    • 使用 man ls 是瞭解這些內容的好起點。

  • 標準:

    • 儘管標準有時會破碎，但它們仍然提供了有用的資訊。

  • 核心原始碼:

    • 核心原始碼是獲取詳細資訊的最佳來源，可能比想象中不那麼令人畏懼。
      到這裡還不關注嗎？

相關文章