- NGINX Rift là PoC thực thi mã từ xa cho CVE-2026-42945, một lỗi tràn bộ đệm heap nghiêm trọng trong
ngx_http_rewrite_module của NGINX
- Lỗ hổng này cho phép thực thi mã từ xa không cần xác thực trên các máy chủ sử dụng chỉ thị
rewrite và set
- Vấn đề bắt nguồn từ một lỗi được đưa vào năm 2008, xảy ra khi pha tính độ dài và pha sao chép của bộ máy script NGINX xử lý cờ
is_args khác nhau
- Khi chuỗi thay thế
rewrite có chứa ?, is_args được đặt trong bộ máy chính, nhưng phần tính độ dài lại chạy trong một bộ máy con mới được khởi tạo lại về 0, nên chỉ trả về độ dài của phần capture gốc
- Ở giai đoạn sao chép,
ngx_escape_uri và NGX_ESCAPE_ARGS được gọi với trạng thái is_args = 1, khiến mỗi byte có thể escape được mở rộng thành 3 byte và làm tràn bộ đệm heap được cấp phát thiếu bằng dữ liệu URI do kẻ tấn công kiểm soát
- Khai thác sử dụng heap feng shui giữa các request để làm hỏng con trỏ
cleanup của ngx_pool_t lân cận; do không thể chèn byte null vào các byte URI, nó thực hiện spray qua phần thân POST
- Con trỏ bị làm hỏng được chuyển hướng tới một
ngx_pool_cleanup_s giả và được thiết lập để gọi system() khi pool bị hủy
- Cùng với CVE-2026-42945, ba vấn đề hỏng bộ nhớ khác gồm CVE-2026-42946, CVE-2026-40701 và CVE-2026-42934 cũng được hệ thống phân tích bảo mật của depthfirst tự động phát hiện chỉ sau một lần onboarding mã nguồn NGINX
- Các phiên bản bị ảnh hưởng gồm NGINX Open Source 0.6.27–1.30.0 và NGINX Plus R32–R36; các bản đã vá được nêu là Open Source 1.31.0/1.30.1 và Plus R36 P4/R35 P2/R32 P6
- Toàn bộ khuyến cáo từ nhà cung cấp có tại https://my.f5.com/manage/s/article/K000160932, còn chi tiết kỹ thuật được trình bày trong technical write-up
- PoC đã được thử nghiệm trên Ubuntu 24.04.3 LTS và cung cấp quy trình khởi chạy container NGINX dễ bị tấn công rồi mở shell theo thứ tự
./setup.sh, docker compose -f env/docker-compose.yml up, python3 poc.py --shell
1 bình luận
Ý kiến trên Hacker News
Với tư cách là người phụ trách bảo mật, tôi rất mệt vì có quá nhiều phản ứng khẳng định hoặc ám chỉ rằng vấn đề này ít đáng sợ hơn nhiều chỉ vì exploit công khai không vượt qua ASLR
Bài gốc cho rằng có cách vượt qua ASLR một cách ổn định bằng cuộc tấn công này, và tôi nghĩ đó là giả định mặc định đủ đáng tin ngay cả khi chưa có bằng chứng
ASLR chỉ là một kỹ thuật phòng thủ theo chiều sâu khiến việc khai thác khó hơn, và trong đa số trường hợp nếu có đủ thời gian và kỹ năng thì cuối cùng cũng sẽ có cách vượt qua ASLR
Vì các agent LLM, rào cản về thời gian và kỹ năng đó cũng đang hạ thấp dần sau mỗi vài tuần, nên việc xuất hiện một exploit được vũ khí hóa hoàn toàn chỉ còn là vấn đề thời gian; nó có thể được công khai hoặc cũng có thể bị giữ kín
Nói rằng “bật ASLR thì không nguy hiểm” là sai rõ ràng, và rất có hại cho những người tin vào điều đó
Niềm tin sai lầm rằng có thể bỏ qua lỗ hổng bảo mật vì các biện pháp giảm thiểu có thể làm việc khai thác khó hơn đã gây ra rất nhiều thiệt hại trong quá khứ
Việc có các biện pháp giảm thiểu hiện đại là điều đáng mừng, nhưng vẫn phải vá càng sớm càng tốt; và nếu là vendor thì đừng coi báo cáo lỗ hổng là không hợp lệ chỉ vì nhà nghiên cứu chưa đưa ra cách vượt ASLR, mà hãy sửa nguyên nhân gốc rễ
Tuy vậy, ở thời điểm hiện tại các điều kiện tiên quyết có vẻ hơi đặc thù
Trong 10 năm dùng nginx với nhiều cấu hình khác nhau, tôi chưa từng một lần dùng
rewritecùng vớisetVà họ nhất định phải gọi là “cyber”
ASLR giống như một mật khẩu bổ sung phải đoán trúng, có một mức entropy nhất định và thường khá ổn định
Nếu lỗ hổng không có phần rò rỉ thông tin thì ASLR либо có thể giảm thiểu hoàn toàn lỗ hổng đó, hoặc sẽ cần một lỗ hổng thứ hai
Đó là một cuộc thảo luận khác
ASLR có thể giảm thiểu hoàn toàn từng lỗ hổng riêng lẻ, nhưng không thể ngăn cả một chuỗi exploit
Dù vậy, nếu muốn thuyết phục mọi người vá nhanh thì tôi nghĩ tốt hơn nên dựa vào khả năng tồn tại lỗ hổng thứ hai tạo ra rò rỉ thông tin
Chuỗi exploit luôn nguy hiểm với mọi loại lỗ hổng
Điều thực sự có hại là tin nguyên xi vào những bình luận ngẫu nhiên trên Internet được viết với sự tự tin tuyệt đối
Nếu rèn được khả năng nhìn thấu chuyện đó thì không chỉ bảo mật mà nhiều lĩnh vực khác cũng sẽ có ích
Đó là lý do tôi đọc những báo cáo như thế này, và phải xem chúng một cách nghiêm túc
Nếu không, sớm muộn máy cũng sẽ bị đột nhập
Gần đây có vẻ nhiều exploit thực thi mã từ xa được công bố mà không có thông báo trước, và ít nhất tôi cũng mong có vài phút để nâng cấp phần mềm
Cảm giác như quay lại thời cuối thập niên 1980 đến đầu thập niên 1990, khi các lỗi sendmail có thể exploit từ xa xuất hiện dồn dập và việc công bố gần như không có rào chắn an toàn nào
Nếu không đọc các báo cáo như vậy, hoặc đọc quá muộn, hàng triệu máy có thể bị xâm nhập
Hiện tại nginx chiếm khoảng 39~43% thị trường web server công khai, nên đây là chuyện khá nghiêm trọng
Vụ này khá tệ, nhưng có điều kiện tiên quyết
Cần một chỉ thị
rewritecó dấu hỏi trong chuỗi thay thế, và sau đó phải có một chỉ thịsettham chiếu tới nhóm capture của regexVí dụ:
set $var $1Ngoài ra, bản proof-of-concept giả định ASLR bị tắt
Kể cả tự tắt thủ công thì nginx cũng không phải thứ khiến tôi nghĩ tới đầu tiên
rewritenữa đúng không?Tôi nhớ nó nhiều hơn từ thời PHP và Apache ngày xưa
Đây là trang chính thức của F5: https://my.f5.com/manage/s/article/K000161019
Như đã được viết ở nơi khác, ASLR có tác dụng bảo vệ
Trong lúc chờ bản sửa cho các nền tảng bị ảnh hưởng, họ hướng dẫn biện pháp giảm thiểu là “dùng capture có tên thay vì capture không tên trong định nghĩa
rewrite”Cụ thể là “để giảm thiểu lỗ hổng trong ví dụ này, hãy thay
$1và$2bằng các capture có tên phù hợp là$user_id,$section”F5 đã vá 1.31.0 và 1.30.1
OpenResty có bản vá cho 1.27 và 1.29: https://github.com/openresty/openresty/commit/ee60fb9cf645c9...
Có thể theo dõi tiến triển của OpenResty, máy chủ ứng dụng Lua dựa trên Nginx, tại đây: https://github.com/openresty/openresty/issues/1119
Bản proof-of-concept tắt ASLR: https://github.com/DepthFirstDisclosures/Nginx-Rift/blob/mai...
forktừ master nên nhận cùng một bố cục bộ nhớCó thể làm crash worker không giới hạn số lần
Khả năng cao là có cách lợi dụng điều này để tạo một read oracle
Ít nhất cũng có thể gây từ chối dịch vụ một cách ổn định
Phân tích đầy đủ của Depth First: https://depthfirst.com/research/nginx-rift-achieving-nginx-r...
Có lựa chọn thay thế tốt nào cho Apache và Nginx được viết bằng ngôn ngữ an toàn bộ nhớ và không có quá nhiều lỗ hổng bảo mật không?
Tôi có xem qua Jetty viết bằng Java và Caddy viết bằng Go, nhưng Jetty có lịch sử các loại lỗ hổng khác như shell injection nên tôi không chắc nó có thực sự tốt hơn không
Ngày nay người vận hành hạ tầng nên làm quen với phòng thủ chủ động là MAC, tức SELinux và AppArmor
Trước đây ma sát khá lớn, nhưng giờ có nhiều công cụ giúp việc sử dụng dễ hơn
https://presentations.nordisch.org/apparmor/
https://github.com/nobody43/apparmor-profiles/blob/master/ng...
https://github.com/nobody43/apparmor-suggest
Nhân tiện, cả hai kho này đều do tôi tự làm
Việc cả hai giữ được thị phần lâu như vậy thực ra còn là tín hiệu tốt
Tuy vậy, mô hình tạo ra hàng nghìn binary tùy theo tổ hợp plugin mong muốn, thay vì một hệ thống plugin tử tế, thì hơi dở
Dù thế, nếu build từ source thì nó khá gọn gàng và đơn giản
Phần lớn các HTTP server thay thế đều thu hẹp phạm vi khá nhiều, nên trước tiên phải xác định mình cần tính năng gì
Tôi cũng không thấy nhiều thảo luận về HTTP server viết bằng ngôn ngữ an toàn bộ nhớ
Ba server C lớn là Apache, Nginx và lighttpd đều khá vững, và dường như không nhiều người muốn chuyển sang dự án mới chỉ vì ngôn ngữ
Ngoài ra, chọn hầu hết các ngôn ngữ an toàn bộ nhớ cũng đồng nghĩa chấp nhận runtime hoặc máy ảo, cùng nhiều thành phần phụ trợ, đôi khi rất đồ sộ, của ngôn ngữ đó
Với web server Java thì cũng có khả năng dùng log4j, giống như nhiều dự án Java ngẫu nhiên khác
“Exploit dùng heap feng shui xuyên qua nhiều request” — đây là lần đầu tôi thấy feng shui được dùng theo kiểu này
Debian 12 đã vá cái này chưa?
Dù sao thì có thể hiểu là nếu không dùng
rewritehaysetở đâu cả thì sẽ không bị ảnh hưởng đúng không?Có vẻ Debian vẫn chưa vá trixie
setcó lẽ là rất hiếmHầu hết các trường hợp dùng nginx là để terminate TLS rồi chuyển request sang node/php/go v.v.
Nên tôi nghĩ sẽ có ít nhất một dòng
setchứa dữ liệu do kẻ tấn công kiểm soát, kiểu nhưproxy_set_header X-Host $host;Đính chính: có vẻ capture có tên không bị ảnh hưởng
Nếu không có
$1ở đâu đó thì có lẽ ổnLink tốt hơn:
https://depthfirst.com/research/nginx-rift-achieving-nginx-r... (https://news.ycombinator.com/item?id=48126029)
https://depthfirst.com/nginx-rift (https://news.ycombinator.com/item?id=48123365)