Cách Cloudflare ứng phó với lỗ hổng "Copy Fail" nghiêm trọng trên Linux

Ngày 29 tháng 4 năm 2026, cộng đồng bảo mật đã chấn động trước việc công bố một lỗ hổng nghiêm trọng trong nhân Linux dưới tên gọi "Copy Fail" (CVE-2026-31431). Đây là lỗ hổng leo thang đặc quyền cục bộ (local privilege escalation), cho phép kẻ tấn công nâng quyền hạn từ người dùng thường lên root. Ngay khi thông tin được tiết lộ, đội ngũ An ninh và Kỹ thuật của Cloudflare đã lập tức vào cuộc để đánh giá và bảo vệ hạ tầng toàn cầu của mình.

Cloudflare Linux Infrastructure

Bối cảnh hạ tầng Linux của Cloudflare

Cloudflare vận hành một hạ tầng máy chủ Linux khổng lồ trải dài trên 330 thành phố. Để quản lý hiệu quả quy mô này, họ duy trì các bản dựng nhân Linux tùy chỉnh dựa trên các phiên bản LTS (Hỗ trợ dài hạn) của cộng đồng. Tại bất kỳ thời điểm nào, hệ thống có thể đang chạy nhiều phiên bản LTS khác nhau (ví dụ: 6.12 hoặc 6.18) để tận dụng các bản cập nhật mở rộng.

Quy trình cập nhật của Cloudflare được tự động hóa cao độ: các bản vá bảo mật và ổn định từ cộng đồng sẽ được tích hợp để tạo ra bản dựng nội bộ mới khoảng mỗi tuần. Các bản dựng này trải qua quá trình thử nghiệm nghiêm ngặt tại các trung tâm dữ liệu staging trước khi được triển khai toàn cầu. Nhờ quy trình này, vào thời điểm lỗ hổng Copy Fail được công bố, phần lớn hạ tầng của Cloudflare đã chạy các phiên bản nhân được cập nhật thường xuyên, dù bản vá cụ thể cho lỗi này vẫn đang trong quá trình backport.

Cơ chế hoạt động của lỗ hổng Copy Fail

Để hiểu rõ cách Cloudflare đối phó, chúng ta cần xem xét cách lỗ hổng này hoạt động. Vấn đề nằm ở module algif_aead của nhân Linux, cụ thể là trong cách xử lý socket AF_ALG và hàm splice().

Lỗi này cho phép một quá trình không có đặc quyền thực hiện ghi vượt quá vùng nhớ (out-of-bounds write) lên tới 4 byte. Kẻ tấn công có thể khai thác điều này để sửa đổi bộ nhớ đệm trang (page cache) của các tệp nhị phân setuid (như /usr/bin/su). Bằng cách chèn shellcode vào tệp này, khi tệp được thực thi, mã độc sẽ chạy với quyền root.

Quy trình khai thác điển hình bao gồm:

• Mở tệp mục tiêu (ví dụ /usr/bin/su) để tải vào page cache.
• Sử dụng splice() để liên kết trang nhớ của tệp với scatterlist của API mật mã.
• Gửi dữ liệu được tính toán kỹ lưỡng để ghi đè 4 byte tại một vị trí mong muốn trong tệp thông qua lỗ hổng.
• Thực thi tệp bị sửa đổi để leo thang đặc quyền.

Chiến lược phản ứng của Cloudflare

Khi lỗ hổng được công bố, nhiều nhóm công việc tại Cloudflare đã hoạt động song song để đảm bảo an toàn tuyệt đối.

Xác định phạm vi ảnh hưởng và Đi săn mối đe dọa

Đội ngũ an ninh đã làm việc chặt chẽ với các kỹ sư nhân để xác định các phiên bản nhân dễ bị tổn thương và đánh giá mức độ tiếp xúc. Đồng thời, họ bắt đầu rà soát logs trong 48 giờ trước khi lỗ hổng được công bố. Nguyên tắc của họ là "luôn giả định đã bị xâm phạm cho đến khi chứng minh được điều ngược lại".

Tuy nhiên, cuộc điều tra kỹ lưỡng đã cho thấy không có dấu hiệu khai thác nào trên hệ thống của Cloudflare trước thời điểm công bố. Các tệp nhị phân hệ thống vẫn nguyên vẹn, không có cơ chế duy trì độc hại (persistence mechanism) nào được phát hiện.

Xác thực khả năng phát hiện

Một trong những điểm sáng nhất trong phản ứng này là hệ thống phát hiện hành vi (behavioral detection) hiện có của Cloudflare. Khi kỹ sư của họ thử nghiệm khai thác lỗ hổng trong nội bộ, hệ thống đã tự động phát hiện và gắn cờ cảnh báo chỉ trong vài phút.

Hệ thống này không dựa vào việc biết trước các lỗ hổng cụ thể; nó giám sát các mô hình thực thi quá trình bất thường trên toàn fleet. Nó đã liên kết toàn bộ chuỗi thực thi—từ trình thông dịch script, qua hệ thống con mật mã của nhân, đến tệp nhị phân leo thang đặc quyền—và gắn cờ nó là độc hại. Điều này xảy ra mà không cần bất kỳ cập nhật chữ ký hay thay đổi quy tắc nào.

Mitigation Progress

Giải pháp giảm thiểu rủi ro: bpf-lsm

Việc triển khai bản vá nhân mới (kernel patch) đòi hỏi thời gian và khởi động lại máy chủ (reboot). Do đó, Cloudflare cần một giải pháp giảm thiểu tức thời mà không làm gián đoạn dịch vụ.

Ban đầu, họ cân nhắc gỡ bỏ module algif_aead gây lỗi. Tuy nhiên, việc này sẽ ảnh hưởng đến các phần mềm hợp pháp đang sử dụng API mật mã của nhân. Thay vào đó, Cloudflare đã sử dụng công cụ bpf-lsm (Linux Security Module dựa trên eBPF).

bpf-lsm cho phép chặn các cuộc gọi socket_bind đối với socket AF_ALG. Chỉ những tệp nhị phân nằm trong danh sách cho phép (allow-list) mới được phép sử dụng socket này. Quy trình triển khai bao gồm hai bước:

1. Tăng khả năng hiển thị: Sử dụng prometheus-ebpf-exporter để theo dõi việc sử dụng AF_ALG trên toàn fleet, xác định chính xác dịch vụ nào cần nó.
2. Thực thi chặn: Triển khai chương trình bpf-lsm để chặn mọi nỗ lực bind socket AF_ALG từ các tệp không được phép.

Giải pháp này đã được thử nghiệm thành công trên một nút kiểm thử, xác nhận rằng khai thác không còn hoạt động mà không ảnh hưởng đến dịch vụ hợp pháp.

Kết luận và Bài học

Sự kiện "Copy Fail" là một bài kiểm tra thực tế cho quy trình ứng phó sự cố của Cloudflare. Mặc dù bản vá chính thức chưa được backport kịp thời đến dòng nhân chính mà họ đang sử dụng, nhưng sự kết hợp giữa hệ thống phát hiện hành vi tiên tiến và công cụ giảm thiểu runtime linh hoạt (bpf-lsm) đã giúp bảo vệ toàn bộ hạ tầng.

Không có dữ liệu khách hàng nào bị ảnh hưởng và không có sự gián đoạn dịch vụ nào xảy ra. Cloudflare cam kết sẽ tiếp tục cải thiện khả năng hiển thị vào các phụ thuộc API của nhân và tinh chỉnh các công cụ bpf-lsm để phản ứng nhanh hơn trước các mối đe dọa trong tương lai.

Trách nhiệm công bố (Responsible disclosure) và các công cụ hiển thị trong nhân (in-kernel visibility) đã chứng minh giá trị to lớn của mình trong sự kiện này, giúp bảo vệ Internet trước các cuộc tấn công tinh vi.