- ssh-keysign-pwn là PoC cho một lỗ hổng Linux cho phép người dùng không đặc quyền đọc các tệp do root sở hữu, và cho biết các kernel trước
31e62c2ebbfd là đối tượng bị ảnh hưởng
- Lỗi cốt lõi là
__ptrace_may_access() bỏ qua bước kiểm tra dumpable khi task->mm == NULL, còn do_exit() thì thực thi exit_mm() trước exit_files(), tạo ra một khoảng thời gian mà file descriptor vẫn còn mở
- Trong khoảng thời gian này, nếu uid của bên gọi trùng với tiến trình mục tiêu thì
pidfd_getfd(2) sẽ thành công, cho phép lấy file descriptor đang mở của tiến trình đang trong quá trình thoát
sshkeysign_pwn lấy /etc/ssh/ssh_host_{ecdsa,ed25519,rsa}_key, tận dụng luồng mà ssh-keysign.c mở các khóa có quyền 0600 rồi thoát với EnableSSHKeysign=no trước permanently_set_uid(), để lại fd đang mởchage_pwn lấy /etc/shadow, nhắm vào race khi thoát trong luồng mà chage -l <user> gọi spw_open(O_RDONLY) rồi hạ toàn bộ đặc quyền bằng setreuid(ruid, ruid)- Cách chạy là sau
make, dùng ./sshkeysign_pwn để lấy host key, và ./chage_pwn root để in nội dung /etc/shadow ra standard output; theo mô tả thì sẽ trúng trong vòng 100~2000 lần spawn
- Các môi trường đã được xác nhận gồm Raspberry Pi OS Bookworm 6.12.75, Debian 13, Ubuntu 22.04 / 24.04 / 26.04, Arch và CentOS 9
- Với PoC mục tiêu được kiểm soát,
vuln_target.c mở /etc/shadow rồi hạ quyền, còn exploit_vuln_target.c cho thấy EPERM khi tiến trình còn sống và việc chiếm fd sau SIGKILL
- Lỗ hổng được Qualys báo cáo và Linus đã sửa vào ngày 2026-05-14; bài viết cũng cho biết Jann Horn đã chỉ ra dạng chiếm FD này từ tháng 10/2020
- README đưa ra mục NVD là
https://nvd.nist.gov/vuln/detail/CVE-2026-46333
1 bình luận
Ý kiến trên Lobste.rs
Chỉ vô hiệu hóa ptrace thì không đủ. Dễ bị hiểu nhầm vì message của commit và tên hàm, nhưng
ptrace_may_accessđược gọi từ nhiều đường khác nhau và bản chứng minh khái niệm (PoC) này thực tế cũng không dùng ptraceCó vẻ không có biện pháp giảm thiểu nào thực sự phù hợp, và hiện tại thì chỉ thấy 1) gỡ toàn bộ bit thực thi của
/usr/lib64/misc/ssh-keysignđể chỉ đối phó yếu ớt với đúng PoC này, hoặc 2) dùng thứ như eBPF hay systemtap để chặnpidfd_getfd. Cách đầu chỉ đáng cân nhắc khi không thể vá kernel hay tắt máy mà lại phải đi ngủ ngayTôi chưa xem kỹ PoC, và như mọi khi, vẫn cần cẩn trọng khi chạy PoC bất kỳ lấy từ Internet
Bản khuyến cáo của Qualys vẫn chưa được công bố, và trước đây họ từng nói sẽ rất tiếc khi phải ngừng phát hành qua linux-distros vì chính sách bảo mật của Linux kernel. Mọi thứ đã trở nên khắc nghiệt hơn khi LLM có thể nhanh chóng tạo ra PoC từ các commit sửa lỗi trông đáng ngờ, trong khi trước đây có lẽ còn có thể chờ vài ngày
Qualys thực sự là một đội ngũ xuất sắc, nên khá tiếc khi họ không có được thời điểm phù hợp để tự công bố vụ này. Khi được công bố, tôi tin chắc đó sẽ là một bản khuyến cáo rất tốt
openssh chỉ là mục tiêu thuận tiện cho cuộc tấn công này, chứ không phải bên có lỗi; các binary setuid khác cũng có thể bị chọn làm mục tiêu
/proc/sys/kernel/yama/ptrace_scopethành 2 (admin-only attach) hoặc 3 (no attach) sẽ chặn được mọi khai thác đã biết. Tuy vậy, về lý thuyết vẫn có thể tồn tại cách lạm dụng khácpidfd_getfd, và kết quả ở đây. Cần chạy bằngstap -g block_pidfd_getfd.stp, và cũng như mọi thứ lấy từ Internet, nhất định phải xem kỹ script trước khi chạyTôi mong kernel ngừng tự công bố 0-day bằng cách đẩy các bản sửa lên nhánh chính qua commit công khai. Commit này còn ghi cả “Reported-by: Qualys”, nên rõ ràng đây là bản vá bảo mật
Greg K-H viết rằng đội bảo mật kernel không thể chọn ai được nhận công bố trước đối với các bản vá bảo mật, nên rốt cuộc là không ai được nhận trước cả
Đây không phải vấn đề của ssh mà là vấn đề của Linux. Tiêu đề cũng nên thể hiện như vậy
ssh-keysignkiểm traEnableSSHKeysign=yestrước khi mở host key riêng, thì các hệ thống để tùy chọn này tắt như mặc định đã không dễ bị đánh cắp host key. Khá bất ngờ làssh-keysignkhông kiểm tra tùy chọn này ngay từ đầuPoC ngắn đến mức khiến người ta thấy khá đã, và thiết bị của tôi thực sự cũng dễ bị ảnh hưởng
Có vẻ nó cho phép truy cập vào file descriptor do một file thực thi setuid mở trong những điều kiện nhất định. Tôi không thấy lý do gì việc này chỉ giới hạn ở đọc, và có vẻ có thể bẻ lái thành leo thang đặc quyền cục bộ (LPE) mà không cần bẻ khóa hash
Chỉ riêng PoC này thì có thể làm nó hỏng bằng
chmod -x /usr/lib/openssh/ssh-keysign /usr/bin/chage. Có thể cần đổi đường dẫnssh-keysignvà cũng nên xem trang hướng dẫn. Nhưng như vậy không sửa được vấn đề cốt lõi và có vẻ vẫn có thể bị vượt qua. Theo tôi biết thì chưa có biện pháp giảm thiểu nào khácVấn đề này đã được sửa trong ptrace: slightly saner 'get_dumpable()' logic, và vì thế đã bị lộ ra ngoài. Mới chỉ 10 tiếng trước
Cũng có thông báo công khai của Qualys gửi lên oss-security. Họ nói chưa công bố bản khuyến cáo để cho các bản phân phối và người dùng thời gian vá lỗi. Có vẻ sẽ khá thú vị, và trong lúc chờ thì có thể xem phần giải thích của Brad Spengler từ grsecurity. Có vẻ chính bài đăng này đã châm ngòi cho việc phát triển PoC lần này
exploit_vuln_target/vuln_targetlại hoạt động tốt. Không ổn chút nàoTrên thực tế, có vẻ nó chỉ ảnh hưởng tới các hệ thống đã có người dùng sở hữu tài khoản không đặc quyền. Tức là nếu không có thông tin đăng nhập hợp lệ thì có đúng là không thể dùng cái này để đạt thực thi mã từ xa trực tiếp trên máy chủ SSH phơi ra Internet không?