Cloudflare khắc phục lỗ hổng rò rỉ dữ liệu giữa các tenant trong Containers

Vào ngày 4 tháng 9 năm 2026, Oren Yomtov, một nhà nghiên cứu bảo mật từ Accomplish, đã báo cáo một lỗ hổng ảnh hưởng đến Cloudflare Containers và Cloudflare Sandboxes (được xây dựng dựa trên Containers) thông qua chương trình tiền thưởng lỗi của Cloudflare. Cloudflare đã khắc phục hoàn toàn lỗ hổng này và chúng tôi không có bằng chứng nào cho thấy dữ liệu khách hàng bị xâm phạm.

Bài viết này được chuẩn bị với sự hợp tác của Oren Yomtov và đội ngũ nghiên cứu bảo mật Accomplish, những người có báo cáo chi tiết và thử nghiệm có kiểm soát đã giúp chúng tôi xác thực vấn đề và phản hồi nhanh chóng.

Cloudflare Containers chạy các khối lượng công việc trên cơ sở hạ tầng đa người thuê (multi-tenant) và tự động gán chúng vào các máy chủ đủ điều kiện; khách hàng không thể chọn máy chủ lưu trữ (host) bên dưới. Các nhà nghiên cứu đã chứng minh rằng một khách hàng có tài khoản Workers Paid có thể khôi phục các khối đĩa dư thừa từng được Containers sử dụng trên cùng một máy chủ. Kỹ thuật này không thể nhắm mục tiêu vào một khách hàng, khối lượng công việc, máy chủ hoặc dữ liệu cụ thể nào, và dữ liệu dư thừa cũng không được đảm bảo là sẽ tồn tại.

Cloudflare đã áp dụng bản sửa lỗi trên toàn bộ hệ thống Containers mà không yêu cầu khách hàng thay đổi cấu hình. Trong dữ liệu đo lường I/O đĩa lịch sử mà chúng tôi có, chúng tôi không tìm thấy bằng chứng nào về việc khai thác độc hại. Hoạt động mà chúng tôi có thể quy cho kỹ thuật được báo cáo đến từ các nhà nghiên cứu và các kỹ sư Cloudflare khi thực hiện xác thực được ủy quyền.

Tại đây, chúng tôi giải thích hành vi lưu trữ cơ bản, tác động tiềm tàng, quá trình điều tra và các hành động chúng tôi đã thực hiện để ứng phó.

Cách thức phân bổ lưu trữ container hoạt động

Cloudflare Containers sử dụng tính năng thin provisioning của Linux device mapper (dm-thin) để cung cấp cho mỗi container một đĩa gốc có thể ghi. Mỗi container nằm bên trong một máy ảo chuyên dụng được vận hành bởi trình giám sát máy ảo Firecracker. Firecracker trình bày đĩa này cho máy ảo dưới dạng /dev/vdc.

Thin provisioning chỉ phân bổ lưu trữ vật lý khi một đĩa ảo ghi vào một vùng chưa được ánh xạ trước đó. Các nhóm lưu trữ bị ảnh hưởng sử dụng kích thước khối mỏng (thin-block) là 64 KiB. Khi ổ đĩa mỏng hỗ trợ đĩa gốc của container bị xóa, các khối vật lý của nó được trả về một nhóm phục vụ các khối lượng công việc thuộc về nhiều tài khoản khách hàng khác nhau.

Cấu hình nhóm bị ảnh hưởng bao gồm tùy chọn sau:

skip_block_zeroing

Với tùy chọn này được cấu hình, dm-thin bỏ qua việc xóa các khối mới được phân bổ trước khi làm cho chúng có thể truy cập được. Do đó, khi một khối 64 KiB đã qua sử dụng được gán lại, một thao tác ghi toàn bộ khối sẽ thay thế nội dung trước đó của nó, nhưng một thao tác ghi nhỏ hơn chỉ thay đổi phần được ghi. Phần còn lại có thể vẫn giữ lại dữ liệu từ chủ sở hữu trước đó của khối.

Cách thức khai thác hoạt động

Việc đọc một vùng chưa được ánh xạ của một đĩa mỏng mới không làm lộ dữ liệu dư thừa. Đối với một vùng chưa được ánh xạ của thiết bị mỏng, dm-thin trả về các số không mà không phân bổ một khối vật lý.

Bằng chứng khái niệm (proof of concept) đã xác định các vùng căn chỉnh 64 KiB tương ứng với không gian trống trong hệ thống tệp ext4 của khách và ghi một khối 4 KiB đã căn chỉnh vào mỗi vùng.

Khi thao tác ghi như vậy chạm đến một khối mỏng chưa được ánh xạ, dm-thin đã phân bổ một khối vật lý 64 KiB từ nhóm dùng chung. Thao tác ghi 4 KiB chỉ thay thế phần đó của khối, và vì tính năng xóa khối đã bị vô hiệu hóa, 60 KiB còn lại có thể giữ lại dữ liệu từ một container trước đó.

Do đó, một thao tác đọc thiết bị thô (raw-device read) sau đó có thể quan sát các byte mà container mới chưa từng ghi.

Bằng chứng khái niệm đã thực hiện các bước sau:

1. Tạo một container bằng tài khoản Workers Paid.
2. Mở đĩa gốc có thể ghi tại /dev/vdc.
3. Đọc đĩa và ghi lại dữ liệu cơ sở (baseline).
4. Ghi một khối 4 KiB vào mỗi vùng 64 KiB được chọn tương ứng với không gian trống của ext4.
5. Đọc lại các khối kết quả.
6. Chỉ kiểm tra các phần không bị ghi đè bởi container mới.

Bài nộp bao gồm số lượng, độ lệch khối (block offsets), kích thước, kết quả kiểm tra tổng (checksum) và các tiền tố băm bị cắt bớt. Mặc dù các nhà nghiên cứu đã khôi phục các khối thô để xác thực vấn đề, các tài liệu cung cấp cho Cloudflare không chứa tên tệp, định danh, thông tin xác thực, tên máy chủ, địa chỉ hoặc giá trị nội dung khôi phục của bên thứ ba. Như được mô tả bên dưới, các nhà nghiên cứu cũng đã xác nhận rằng họ đã xóa an toàn dữ liệu được khôi phục.

Cách thức lỗ hổng được xác thực

Các nhà nghiên cứu đã sử dụng các kiểm tra tổng khối thư mục ext4 để phân biệt các khối thuộc về hệ thống tệp thử nghiệm của riêng họ (được tạo cho bằng chứng khái niệm) với các khối bắt nguồn từ các hệ thống tệp khác.

Khi ext4 sử dụng tính năng metadata_csum, các kiểm tra tổng khối thư mục sẽ kết hợp các giá trị liên quan đến hệ thống tệp và inode.

Trên sáu vị trí triển khai thực tế, các nhà nghiên cứu đã báo cáo:

• Tất cả 5.614 khối thư mục có thể kiểm tra.
• Không có khối nào trong số đó được quy cho hệ thống tệp của các nhà nghiên cứu.
• 2.700 inode thư mục nước ngoài riêng biệt được xác định thông qua phân tích kiểm tra tổng.

Để xác thực phương pháp, các nhà nghiên cứu đã thử nghiệm nó đối với các khối mà họ đã cố tình tạo và xóa trong hệ thống tệp thử nghiệm có kiểm soát được sử dụng cho bằng chứng khái niệm. Phương pháp này đã quy chính xác tất cả 162 khối cho hệ thống tệp đó.

Các nhà nghiên cứu cuối cùng đã quan sát thấy dữ liệu dư thừa trên 18 trong số 24 vị trí triển khai và 20 trong số 22 nút cơ sở trên bốn châu lục. Các loại khối được khôi phục bao gồm cấu trúc thư mục, trang cơ sở dữ liệu và các cơ sở dữ liệu SQLite hoàn chỉnh về cấu trúc. Các nhà nghiên cứu báo cáo đã sử dụng các tập lệnh chỉ xuất ra tổng số lượng và kiểm tra định dạng, không phải nội dung tệp được khôi phục. Các tài liệu gửi cho Cloudflare không chứa giá trị nội dung được khôi phục hoặc định danh của bên thứ ba. Các nhà nghiên cứu sau đó đã xác nhận rằng dữ liệu được khôi phục dưới sự kiểm soát của họ vẫn được bảo mật và đã bị xóa an toàn sau khi gửi, phù hợp với chính sách tiết lộ HackerOne của Cloudflare.

Tác động

Lỗ hổng này có khả năng cho phép một khách hàng có tài khoản Workers Paid khôi phục dữ liệu dư thừa từ các khối lưu trữ từng được Containers của các khách hàng khác sử dụng trên cùng một máy chủ lưu trữ.

Một cuộc khai thác thành công sẽ vượt qua ranh giới cô lập người thuê và có thể làm lộ siêu dữ liệu hệ thống tệp, cấu trúc thư mục, trang cơ sở dữ liệu và dữ liệu ứng dụng.

Tuy nhiên, kẻ tấn công không thể chọn một nạn nhân cụ thể hoặc truy cập vào một đĩa đang được gắn kết tích cực. Việc phơi nhiễm phụ thuộc vào vị trí triển khai khối lượng công việc của Cloudflare và các khối đã giải phóng trước đó mà dm-thin gán lại. Hơn nữa, các nhà nghiên cứu không chứng minh được việc sửa đổi dữ liệu đang hoạt động của khách hàng khác hoặc tác động đến tính khả dụng của khối lượng công việc.

Cách chúng tôi giảm thiểu lỗ hổng

Biện pháp giảm thiểu đầu tiên của chúng tôi là loại bỏ skip_block_zeroing khỏi cấu hình nhóm dm-thin trên toàn bộ hệ thống. Điều này khôi phục hành vi mặc định của dm-thin là xóa các khối mới được phân bổ trước khi hiển thị chúng cho một container. Nó đã ngăn chặn kỹ thuật được báo cáo, trong đó một thao tác ghi nhỏ kích hoạt việc phân bổ và một thao tác đọc lớn hơn khôi phục dữ liệu dư thừa từ phần còn lại của khối. Các nhà nghiên cứu đã xác nhận độc lập rằng bằng chứng khái niệm của họ không còn hoạt động sau thay đổi này.

Việc xóa các phân bổ mới không làm sạch các khối đã được ánh xạ vào các thin device hiện có. Các ánh xạ này tồn tại trong các đĩa container đang chạy và trong bộ nhớ đệm (cache) của mỗi máy chủ chứa các bản snapshot dm-thin đã chuẩn bị cho các lớp OCI image. Một container mới có thể kế thừa các ánh xạ từ một lớp đã lưu trong cache mà không cần phân bổ lại các khối đó, cho phép các byte dư thừa trong các vùng không sử dụng, bao gồm cả không gian trống của ext4, vẫn có thể đọc được thông qua các lệnh đọc thô (raw reads) từ /dev/vdc.

Do đó, chúng tôi cũng đã loại bỏ tất cả các đĩa container đang chạy và xóa các bản snapshot image đã lưu trong cache được tạo trước khi áp dụng biện pháp giảm thiểu. Chúng tôi đã thực hiện rút tải các máy chủ trong giờ thấp điểm, khởi động lại các VM trên mỗi máy chủ và xóa bộ nhớ đệm image của từng máy chủ để các đĩa và các lớp đã lưu trong cache được tạo lại bằng các phân bổ đã được xóa sạch (zeroed). Chúng tôi đã hoàn tất quá trình dọn dẹp này trên toàn bộ hệ thống Containers.

Không có bằng chứng về việc khai thác

Là một phần trong phản hồi của mình, chúng tôi đã điều tra xem liệu các khối lượng công việc (workload) khác có cho thấy hoạt động nào nhất quán với kỹ thuật khai thác được báo cáo hay không. Chúng tôi đã xem xét dữ liệu đo từ xa (telemetry) về I/O đĩa lịch sử được lưu giữ từ cơ sở hạ tầng container của mình, sử dụng bằng chứng khái niệm (proof of concept) của các nhà nghiên cứu và hoạt động tái tạo nội bộ của chúng tôi làm tài liệu tham khảo.

Bằng chứng khái niệm đã tạo ra một mối quan hệ đặc trưng giữa các thao tác ghi và đọc. Khi một thao tác ghi 4 KiB chạm tới một vùng chưa được ánh xạ trước đó, nó có thể kích hoạt việc phân bổ một khối lưu trữ 64 KiB được tái sử dụng. Khi tính năng xóa sạch (zeroing) bị vô hiệu hóa, 60 KiB còn lại có thể vẫn giữ lại dữ liệu từ một container trước đó. Do đó, các thao tác đọc sau đó có thể khôi phục lượng dữ liệu lớn hơn đáng kể so với những gì container mới đã ghi đè.

Sử dụng các đặc điểm này, chúng tôi đã phát triển các chữ ký phát hiện (detection signatures) và áp dụng chúng vào dữ liệu đo từ xa lịch sử mà chúng tôi có. Chúng tôi đã xác định được hoạt động liên quan đến các nhà nghiên cứu và các kỹ sư Cloudflare đang thực hiện xác thực được ủy quyền, và không xác định được thêm bất kỳ hoạt động nào khác nhất quán với kỹ thuật được báo cáo.

Chúng tôi không thấy bằng chứng nào cho thấy vectơ tấn công cụ thể này đã bị bất kỳ ai khác khai thác.

Bài gốc còn tiếp — xem tiếp tại bài gốc ↗