Tái thẩm định tấn công Spectre từ xa trên Cloudflare Workers: Rò rỉ 12 bit/giây và bài học bảo mật

Năm 2021, Cloudflare từng đánh giá mức độ rủi ro của tấn công Spectre từ xa đối với nền tảng Cloudflare Workers và tung ra cơ chế phòng thủ mang tên Dynamic Process Isolation (DyPrIs). Tuy nhiên, với sự phát triển của các kỹ thuật mới trong lĩnh vực ổn định hóa tấn công Spectre, đội ngũ bảo mật của Cloudflare đã quyết định tái thẩm định toàn diện để hiểu rõ hơn về mối đe dọa thực tế trong môi trường sản xuất.

Kết quả nghiên cứu vừa được công bố đã hé lộ một giới hạn quan trọng trong DyPrIs: kẻ tấn công có thể khai thác thành công lỗ hổng Spectre từ xa, rò rỉ dữ liệu với tốc độ lên tới 12 bit/giây và độ chính xác hơn 99%. Dù lỗ hổng đã được vá, nghiên cứu này vẫn là hồi chuông cảnh tỉnh cho toàn ngành công nghệ về mức độ tinh vi của các cuộc tấn công vi kiến trúc (microarchitectural) trong môi trường đám mây hiện đại.


Mô hình bảo mật của Cloudflare Workers

Cloudflare Workers chạy mã JavaScript không tin cậy (untrusted) trên biên (edge). Thay vì cô lập từng tenant bằng tiến trình riêng biệt, nền tảng này sử dụng V8 isolates — cho phép hàng chục nghìn tenant chia sẻ chung một tiến trình hệ điều hành. Mỗi Worker có một JavaScript heap riêng, giúp giảm độ trễ khởi động và tăng hiệu suất so với cô lập tiến trình truyền thống.

Xung quanh runtime, Cloudflare triển khai nhiều lớp phòng thủ như:

• Đường ống vá lỗi V8 tự động
• Sandbox hai lớp bao gồm Linux namespaces và seccomp filters
• Cap’n Proto RPC cho giao tiếp liên tiến trình
• Khả năng lập lịch các script đáng ngờ vào sandbox tiến trình riêng

Tuy nhiên, một lỗ hổng đọc bộ nhớ tùy ý (arbitrary read) bên trong tiến trình Worker vẫn có thể dẫn đến rò rỉ dữ liệu giữa các tenant. Và Spectre — tấn công khai thác cơ chế thực thi suy đoán (speculative execution) — chính là một trong những lỗ hổng khó vá nhất.

Spectre hoạt động như thế nào?

Hãy tưởng tượng việc đi bộ đường núi: đến một ngã rẽ, bạn phải dự đoán hướng đi. Nếu dự đoán đúng, bạn tiết kiệm thời gian. Nếu sai, bạn phải quay lại — nhưng dấu chân vẫn còn in trên bùn đất.

CPU cũng hoạt động tương tự với dự đoán nhánh (branch prediction). Khi dự đoán sai, CPU phải hủy kết quả và thực thi nhánh còn lại. Tuy nhiên, các lệnh được thực thi tạm thời này (gọi là transient instructions) vẫn để lại dấu vết trong trạng thái vi kiến trúc — đặc biệt là trong bộ nhớ cache của CPU.

Kẻ tấn công có thể lợi dụng Spectre để truy cập bộ nhớ ngoài phạm vi một cách tạm thời, mã hóa một bit thông tin vào trạng thái cache, sau đó đo độ trễ truy cập lại để suy ra bit đó là 0 hay 1.

Để chống lại Spectre trong tiến trình, Cloudflare Workers đã áp dụng các biện pháp:

• Đóng băng bộ định thời cục bộ (local timers)
• Vô hiệu hóa đa luồng và bộ nhớ dùng chung
• Phát hiện và cô lập các script có hành vi đáng ngờ
• Xáo trộn bộ nhớ (memory shuffling) định kỳ

Các nguyên thủy tấn công trong nghiên cứu

Gadget Spectre — mảnh ghép quan trọng

Nghiên cứu sử dụng hai loại gadget Spectre khác nhau:

1. Gadget rò rỉ con trỏ heap nén — khai thác để lấy địa chỉ cơ sở của heap isolate
2. Gadget nhầm lẫn kiểu suy đoán (speculative type confusion) — cho phép đọc từ một con trỏ 64-bit tùy ý do kẻ tấn công tạo ra

return probeArray[
  obj instanceof ObjP
  ? PROBEARRAY_OFFSET + ((obj.ptr[0] >> bit) & 1) * 0x800
  : 0x400
];

Gadget này hoạt động bằng cách huấn luyện sai bộ dự đoán nhánh: gọi gadget nhiều lần trên các đối tượng hợp lệ, sau đó gọi với một đối tượng khác có bố cục bộ nhớ do kẻ tấn công kiểm soát. CPU suy đoán và thực thi transient access, từ đó mã hóa một bit vào trạng thái cache.


Khuếch đại tín hiệu — vượt qua giới hạn bộ định thời

Khác biệt giữa cache hit và cache miss chỉ vài nano giây — quá nhỏ so với độ nhiễu của bộ định thời từ xa (micro giây đến milli giây). Giải pháp đến từ nghiên cứu của Stephen Röttger và Artur Janc: khai thác chính sách thay thế cache PLRU (Pseudo Least Recently Used) trong L1 cache.

Bằng cách sử dụng các mẫu truy cập đặc biệt, kẻ tấn công có thể ép CPU vào trạng thái mà một sự kiện cache đơn lẻ dẫn đến hàng loạt cache hit (nếu bit là 1) hoặc hàng loạt cache miss (nếu bit là 0). Sự khác biệt này đủ lớn để đo được ngay cả với bộ định thời nhiễu.


Bộ định thời từ xa — không cần SharedArrayBuffer

Cloudflare Workers vô hiệu hóa SharedArrayBuffer, đa luồng và các bộ định thời độ phân giải cao. Nhưng nghiên cứu chứng minh rằng chỉ cần một kết nối WebSocket đến máy chủ bên ngoài trả về timestamp độ phân giải cao là đủ. Máy chủ này có thể đặt tại Cloudflare hoặc một trung tâm dữ liệu gần đó, đạt độ phân giải dưới milli giây chỉ với vài mẫu dữ liệu.

Chiến lược tấn công tổng thể

Đặt chung vị trí (Co-location) — dễ hơn tưởng tượng

Với hàng chục nghìn máy chủ biên, việc kẻ tấn công và nạn nhân nằm trên cùng một máy chủ tưởng chừng khó khăn. Nhưng trên Cloudflare Workers, điều này cực kỳ đơn giản: chỉ cần gọi fetch("https://victim.example") từ script tấn công, scheduler sẽ ưu tiên khởi tạo victim worker trong cùng tiến trình. Thậm chí, kẻ tấn công có thể chọn thời điểm máy chủ ít tải (ví dụ: colo tại Úc vào giờ làm việc châu Âu) để tăng độ ổn định.

Vượt qua giới hạn tài nguyên — Durable Objects cứu cánh

Workers thông thường giới hạn 30 giây CPU và 1.000 subrequest mỗi lần gọi. Nhưng Durable Objects — được thiết kế cho tương tác thời gian thực — xử lý mỗi thông điệp WebSocket như một lần gọi mới, giúp reset giới hạn liên tục.

Bằng cách mở WebSocket bền vững và gửi keep-alive đều đặn, kẻ tấn công có thể giữ isolate sống từ 5 đến hơn 20 giờ đồng hồ — đủ để hoàn thành cuộc tấn công trước khi DyPrIs kịp phản ứng.

Kỹ thuật đo lường lặp lại

Một phép đo đơn lẻ không đủ tin cậy trên máy chủ sản xuất nhiễu. Thay vì xây dựng eviction set phức tạp như cách truyền thống, nghiên cứu áp dụng ý tưởng từ Dougall Johnson dựa trên nguyên lý chuồng bồ câu (pigeonhole principle): cấp phát vùng nhớ lớn hơn nhiều so với dung lượng cache, khi đó một vị trí ngẫu nhiên gần như chắc chắn đã bị đẩy khỏi cache.

for (let s = 0; s < SAMPLE_NUM; s++) {
  timer.mark("mark S" + s);
  for (let r = 0; r < OUTER_REP_NUM; r++) {
    setup();                   // huấn luyện sai nhánh và kiểm soát cache
    leak(secretBit);           // truy cập transient
    PLRU(cacheSet, INNER_REP); // khuếch đại tín hiệu
  }
  timer.mark("mark E" + s);
}
delta = fetchFromServer(SAMPLE_NUM);
return median(delta);

Kết quả thực nghiệm

Nhóm nghiên cứu đã triển khai tấn công end-to-end trong môi trường sản xuất Cloudflare Workers:

1. Rò rỉ isolate root từ một Worker
2. Xác nhận đọc 64-bit thông qua vùng vDSO (chứa các chuỗi dễ nhận biết như "gettimeofday")
3. Rò rỉ JWT token được đặt cố ý trong victim Worker — bit theo bit

Kết quả: tốc độ rò rỉ lên tới 12 bit/giây với độ chính xác hơn 99% trong điều kiện sản xuất, ngay cả khi CPU sử dụng cao.


Vì sao DyPrIs không phát hiện được?

Hai điểm mù chính được xác định:

1. Cơ chế cô lập quá chậm: DyPrIs chỉ cô lập script sau khi invocation kết thúc. Thủ thuật giữ kết nối WebSocket qua Durable Objects cho phép tấn công hoàn tất trong nhiều giờ trước khi bị phát hiện.

2. Kỹ thuật "ngụy trang": DyPrIs chuẩn hóa tỷ lệ dự đoán nhánh sai theo số lần truy cập iTLB. Vòng lặp I/O lớn từ WebSocket làm tăng đáng kể hoạt động iTLB, khiến tỷ lệ chuẩn hóa giảm xuống dưới ngưỡng phát hiện — tấn công trông giống như một Worker thông thường.

Các biện pháp khắc phục Cloudflare đã triển khai

V8 Sandbox

Mục tiêu cuối cùng là loại bỏ con trỏ 64-bit thô khỏi phần lớn JavaScript heap, giảm hiệu quả của các gadget khai thác lỗ hổng bộ nhớ. Với V8 Sandbox, gadget nhầm lẫn kiểu suy đoán sử dụng trong nghiên cứu không còn hoạt động vì typed-array backing store không còn phơi bày cấu trúc con trỏ thô như trước.

Cô lập trong tiến trình bằng Memory Protection Keys (MPK)

Triển khai từ tháng 9/2025, MPK cho phép tiến trình chia bộ nhớ thành nhiều vùng bảo vệ (protection domains) và chuyển đổi quyền truy cập với chi phí thấp. Mỗi heap isolate nằm sau một ranh giới truy cập do phần cứng thực thi — truy cập vào trang bị bảo vệ sai khóa (key) sẽ bị phần cứng từ chối, chặn đứng cuộc đọc heap chéo isolate.

Cải tiến DyPrIs

Cloudflare xử lý các trường hợp thực thi dài và workload nặng I/O như các trường hợp bảo mật hạng nhất — phát hiện không thể chỉ diễn ra sau khi script kết thúc. Họ cũng đang nghiên cứu thêm hành vi định thời từ xa như một chiều tín hiệu mới: các mẫu bit rò rỉ qua I/O lặp lại quanh các phần compute-heavy nên được coi là tín hiệu hành vi, không phải nhiễu nền.

Bài học cho cộng đồng

Nghiên cứu này nhắc lại một thực tế quan trọng: Spectre không phải là bài toán có lời giải cuối cùng. Mỗi biện pháp phòng thủ mới có thể bị vượt qua bởi các kỹ thuật tinh vi hơn. Đối với các nền tảng chạy mã không tin cậy (untrusted code), chiến lược phòng thủ theo chiều sâu (defense in depth) — kết hợp sandbox, cô lập phần cứng, phát hiện hành vi và vá lỗi liên tục — vẫn là phương án khả thi nhất hiện nay.

Cloudflare cho biết họ chưa ghi nhận bất kỳ dấu hiệu khai thác thực tế nào trong ba năm qua, nhưng vẫn kêu gọi cộng đồng bảo mật tham gia chương trình Bug Bounty — đặc biệt cho các lỗ hổng an toàn bộ nhớ trong runtime — thông qua mã nguồn mở workerd và tích hợp Fuzzilli.