Dữ liệu đã xóa khỏi một container chưa chắc đã biến mất khỏi lớp lưu trữ vật lý. Một lỗ hổng trong Cloudflare Containers vừa được công bố cho thấy cấu hình tối ưu hiệu năng ở tầng cấp phát ổ đĩa có thể làm suy yếu ranh giới cách ly đa khách hàng. Sự cố đã được Cloudflare khắc phục trên toàn bộ hệ thống và hãng cho biết chưa phát hiện bằng chứng khai thác trái phép.
Lỗ hổng Cloudflare Containers là gì?
Ngày 4/9/2026, nhà nghiên cứu Oren Yomtov của Accomplish báo cáo qua chương trình bug bounty của Cloudflare rằng một khách hàng sử dụng tài khoản Workers trả phí có thể khôi phục các khối dữ liệu còn sót lại từ container của khách hàng khác từng chạy trên cùng máy chủ vật lý. Cloudflare Sandboxes, dịch vụ được xây dựng trên Containers để chạy mã không đáng tin cậy, cũng chịu ảnh hưởng.
Đây là lỗi cross-tenant data exposure, tức rò rỉ dữ liệu xuyên ranh giới khách hàng. Kẻ khai thác không thể chọn nạn nhân, máy chủ hay workload cụ thể; dữ liệu thu được cũng không đến từ ổ đĩa đang được một container khác sử dụng. Dù vậy, việc đọc được bất kỳ dữ liệu nào của tenant khác vẫn là vi phạm nghiêm trọng nguyên tắc cách ly trên nền tảng đám mây.
Thin provisioning và khối lưu trữ 64 KiB
Cloudflare dùng Linux device mapper thin provisioning (dm-thin) để cấp ổ đĩa gốc có thể ghi cho container. Mỗi container chạy trong một máy ảo Firecracker riêng và nhìn thấy ổ này dưới tên /dev/vdc. Thin provisioning chỉ cấp phát không gian vật lý khi ổ ảo thực sự ghi vào vùng chưa được ánh xạ, giúp sử dụng dung lượng hiệu quả hơn.
Các storage pool bị ảnh hưởng dùng khối 64 KiB. Khi một container bị xóa, các khối vật lý của nó được trả về pool dùng chung cho workload của nhiều tài khoản. Cấu hình lại bật tùy chọn skip_block_zeroing, khiến dm-thin không ghi số 0 để làm sạch khối cũ trước khi cấp cho tenant mới.
Vì sao một lần ghi 4 KiB có thể làm lộ 60 KiB cũ?
Nếu container mới ghi trọn khối 64 KiB, dữ liệu cũ sẽ bị thay thế. Nhưng proof of concept chỉ ghi 4 KiB vào một vùng trống được căn chỉnh theo ranh giới 64 KiB. Thao tác này buộc hệ thống cấp một khối vật lý đã qua sử dụng, trong khi chỉ 4 KiB đầu được ghi đè. Do việc zeroing bị bỏ qua, 60 KiB còn lại có thể vẫn chứa byte của chủ sở hữu trước.
Đọc thô toàn bộ thiết bị sau đó cho phép quan sát phần dữ liệu mà container mới chưa từng ghi. Điểm đáng chú ý là đọc một vùng hoàn toàn chưa ánh xạ chỉ trả về số 0; nhà nghiên cứu phải chủ động kích hoạt cấp phát bằng thao tác ghi nhỏ rồi mới đọc lại khối lớn hơn.
Những loại dữ liệu nào có thể bị lộ?
Trong thử nghiệm sản xuất có kiểm soát, nhóm nghiên cứu quan sát thấy vật liệu còn sót lại ở 18 trong 24 lần placement và trên 20 trong 22 node cơ sở tại bốn châu lục. Các khối được nhận diện gồm cấu trúc thư mục, trang cơ sở dữ liệu và cơ sở dữ liệu SQLite còn nguyên cấu trúc.
Nhóm nghiên cứu cho biết công cụ phân tích chỉ xuất số đếm tổng hợp và kết quả kiểm tra định dạng. Tài liệu gửi Cloudflare không chứa tên tệp, thông tin định danh, thông tin xác thực hay nội dung của bên thứ ba; dữ liệu khôi phục được giữ bí mật và xóa an toàn sau khi báo cáo.
Giới hạn của phương thức khai thác
Lỗ hổng không cho phép nhắm tới một khách hàng cụ thể, không truy cập ổ đĩa đang gắn với workload khác và không chứng minh được khả năng sửa dữ liệu đang hoạt động hay gây gián đoạn dịch vụ. Kết quả phụ thuộc vào thuật toán placement của Cloudflare và việc pool có cấp lại đúng khối từng chứa dữ liệu hay không.
Những giới hạn này làm giảm tính xác định của cuộc tấn công nhưng không loại bỏ rủi ro. Các tệp môi trường, token, cookie phiên hoặc trang cơ sở dữ liệu chỉ cần xuất hiện ngẫu nhiên trong dữ liệu dư là có thể tạo ra tác động bảo mật đáng kể.
Cloudflare đã khắc phục như thế nào?
Biện pháp đầu tiên là loại bỏ skip_block_zeroing trên toàn bộ fleet, khôi phục hành vi mặc định: mọi khối mới cấp phải được làm sạch trước khi container truy cập. Accomplish xác nhận proof of concept không còn hoạt động sau thay đổi này.
Tuy nhiên, zeroing chỉ bảo vệ lần cấp phát mới. Các khối đã ánh xạ trong ổ đĩa container đang chạy và snapshot image được cache vẫn có thể chứa byte cũ. Vì vậy, Cloudflare tiếp tục cho ngừng toàn bộ ổ container đang chạy, xóa cache image, drain máy chủ vào giờ thấp điểm và khởi tạo lại lớp lưu trữ. Quá trình dọn dẹp hoàn tất ngày 19/9.
Dòng thời gian phản ứng
- 4/9: Accomplish báo cáo lỗi; Cloudflare xác nhận cấu hình gây ra vấn đề và bắt đầu triển khai bản sửa.
- 7/9: Thay đổi cấu hình hoàn tất trên fleet, đồng thời quá trình xóa dữ liệu pool cũ được khởi động.
- 14/9: Nhà nghiên cứu xác nhận proof of concept đã ngừng hoạt động.
- 19/9: Cloudflare hoàn tất xóa các cached snapshot được tạo trước khi giảm thiểu.
- 24/9: Cloudflare công khai phân tích kỹ thuật và khẳng định khách hàng không cần thay đổi cấu hình.
Khách hàng cần làm gì?
Cloudflare cho biết lỗ hổng đã được vá ở phía dịch vụ nên khách hàng không cần thực hiện thao tác kỹ thuật. Hãng xây dựng chữ ký phát hiện từ proof of concept, đối chiếu với telemetry I/O lịch sử còn lưu giữ và chỉ thấy hoạt động của nhóm nghiên cứu cùng kỹ sư Cloudflare được ủy quyền. Chưa có bằng chứng phương thức này bị bên khác khai thác.
Dẫu vậy, tổ chức dùng môi trường container để xử lý bí mật nên tiếp tục áp dụng quản lý secret tập trung, token sống ngắn, mã hóa dữ liệu nhạy cảm và xoay vòng thông tin xác thực khi có căn cứ phơi nhiễm. Kiểm soát ở tầng ứng dụng giúp hạn chế hậu quả nếu lớp cách ly hạ tầng gặp lỗi.
Bài học về cách ly đa khách hàng
Sự cố nhấn mạnh rằng cách ly không chỉ phụ thuộc container hay máy ảo. Toàn bộ chuỗi bên dưới — bộ nhớ, block device, cache image và cơ chế tái sử dụng tài nguyên — đều phải có quy tắc làm sạch rõ ràng. Một tùy chọn tưởng như chỉ liên quan hiệu năng có thể biến dữ liệu “đã xóa” thành dữ liệu của tenant kế tiếp.
Với nhà cung cấp đám mây, kiểm thử cần bao phủ cả vòng đời cấp phát, thu hồi và tái cấp phát tài nguyên. Với khách hàng, mô hình trách nhiệm chia sẻ vẫn đòi hỏi giảm lượng bí mật lưu trên ổ cục bộ và thiết kế hệ thống với giả định rằng một lớp phòng thủ riêng lẻ có thể thất bại.
VNCyberS tổng hợp từ Cloudflare và The Hacker News
Tiếng Việt
English