Tấn công Downfall
(downfall.page)- Đây là lỗ hổng CVE-2022-40982 trên các bộ xử lý Intel được dùng rộng rãi trong máy tính cá nhân và đám mây, có thể dùng để đánh cắp dữ liệu của người dùng khác cùng chia sẻ một máy tính
- Cốt lõi của lỗ hổng là trong quá trình tối ưu hóa bộ nhớ, lệnh Gather làm lộ nội dung tệp thanh ghi vector nội bộ trong lúc thực thi suy đoán
- Cuộc tấn công được triển khai bằng các kỹ thuật GDS·GVI, và bản demo cho thấy có thể làm rò rỉ vượt qua ranh giới cô lập như khóa AES, dữ liệu Linux Kernel, thậm chí giám sát các ký tự có thể in ra
- Phạm vi ảnh hưởng là từ Intel Core thế hệ 6 Skylake đến thế hệ 11 Tiger Lake, và người dùng đám mây vẫn có thể bị ảnh hưởng ngay cả khi không trực tiếp sở hữu thiết bị Intel
- Bản cập nhật microcode của Intel chặn kết quả transient của Gather, nhưng một số workload có thể chịu overhead tới 50% sau khi áp dụng biện pháp giảm thiểu
Lỗ hổng mà Downfall nhắm tới
- Downfall nhắm vào một điểm yếu nghiêm trọng trong các bộ xử lý hiện đại dùng cho máy tính cá nhân và máy tính đám mây
- Lỗ hổng này được định danh là CVE-2022-40982
- Nó có thể truy cập và đánh cắp dữ liệu của người dùng khác cùng chia sẻ một máy tính
- Ứng dụng độc hại tải từ app store có thể đánh cắp thông tin nhạy cảm như mật khẩu, khóa mã hóa, thông tin ngân hàng, email cá nhân và tin nhắn
- Trong môi trường đám mây, khách hàng độc hại có thể đánh cắp dữ liệu và thông tin xác thực của khách hàng khác cùng chia sẻ một máy tính đám mây
Nguyên nhân kỹ thuật của lỗ hổng
- Tính năng tối ưu hóa bộ nhớ của bộ xử lý Intel vô tình làm lộ các thanh ghi phần cứng nội bộ cho phần mềm
- Phần mềm không đáng tin cậy có thể truy cập dữ liệu của chương trình khác vốn lẽ ra không thể truy cập
- Lệnh Gather dùng để đọc nhanh dữ liệu rải rác trong bộ nhớ làm rò rỉ nội dung tệp thanh ghi vector nội bộ trong lúc thực thi suy đoán
- Các kỹ thuật Gather Data Sampling (GDS) và Gather Value Injection (GVI) được dùng để khai thác điều này
- Chi tiết kỹ thuật được tổng hợp trong bài báo Downfall
Các trường hợp rò rỉ được xác nhận qua demo
- Demo Downfall cho thấy dữ liệu nhạy cảm có thể bị rò rỉ vượt qua các ranh giới cô lập khác nhau
Hệ thống bị ảnh hưởng và điều kiện tấn công
- Thiết bị bị ảnh hưởng là các thiết bị tính toán dựa trên bộ xử lý Intel Core từ thế hệ 6 Skylake đến thế hệ 11 Tiger Lake
- Danh sách đầy đủ hơn về các bộ xử lý bị ảnh hưởng sẽ được Intel cung cấp trong danh sách affected processors
- Ngay cả khi không có thiết bị vật lý chạy Intel, người dùng đám mây vẫn có thể bị ảnh hưởng
- Intel chiếm hơn 70% thị phần máy chủ
- Kẻ tấn công có thể nhắm đến các thông tin xác thực có giá trị cao như mật khẩu và khóa mã hóa
- Việc đánh cắp thông tin xác thực có thể dẫn đến các cuộc tấn công khác làm tổn hại không chỉ tính bí mật mà còn cả tính sẵn sàng và tính toàn vẹn của hệ thống
- GDS tương đối dễ triển khai trong tấn công thực tế
- Chỉ mất 2 tuần để phát triển một cuộc tấn công end-to-end đánh cắp khóa mã hóa từ OpenSSL
- Kẻ tấn công và nạn nhân chỉ cần cùng chia sẻ một lõi bộ xử lý vật lý
- Trên các máy tính hiện đại có preemptive multitasking và simultaneous multithreading, việc chia sẻ như vậy xảy ra khá thường xuyên
Ranh giới cô lập, SGX và tác động tới trình duyệt
- Downfall cũng ảnh hưởng đến các ranh giới cô lập phổ biến
- máy ảo
- tiến trình
- cô lập user-kernel
- Intel SGX cũng bị ảnh hưởng
- Intel SGX là tính năng bảo mật phần cứng của CPU Intel nhằm bảo vệ dữ liệu người dùng khỏi phần mềm độc hại
- Việc khai thác từ xa thông qua trình duyệt web là có thể về mặt lý thuyết
- Tuy nhiên, để chứng minh một cuộc tấn công thành công trong trình duyệt thực tế sẽ cần thêm nghiên cứu và công sức kỹ thuật
Thời gian phơi nhiễm và độ khó phát hiện
- Người dùng đã bị phơi nhiễm với lỗ hổng này trong ít nhất 9 năm
- Các bộ xử lý bị ảnh hưởng đã tồn tại từ năm 2014
- Các cuộc tấn công Downfall rất khó bị phát hiện
- Hình thức thực thi của chúng phần lớn trông giống ứng dụng bình thường
- Về mặt lý thuyết, có thể xây dựng hệ thống phát hiện hành vi bất thường như cache miss quá mức bằng hardware performance counter
- Phần mềm antivirus thương mại thông thường không thể phát hiện kiểu tấn công này
Biện pháp giảm thiểu và overhead hiệu năng
- Intel đã phát hành bản cập nhật microcode
- Bản cập nhật này chặn các kết quả transient của lệnh Gather
- Nó ngăn mã của kẻ tấn công quan sát dữ liệu suy đoán phát sinh từ Gather
- Overhead của biện pháp giảm thiểu phụ thuộc vào việc Gather có nằm trên đường thực thi quan trọng của chương trình hay không
- Theo Intel, một số workload có thể chịu overhead tới 50%
- Không an toàn nếu tắt biện pháp giảm thiểu chỉ vì workload không dùng Gather
- CPU hiện đại dùng thanh ghi vector để tối ưu các tác vụ phổ biến như sao chép bộ nhớ và chuyển đổi nội dung thanh ghi
- Trong quá trình đó, dữ liệu có thể bị rò rỉ sang mã không đáng tin cậy khai thác Gather
Lịch công bố và mã tái hiện
- Lỗ hổng này đã bị giữ trong tình trạng embargo gần 1 năm
- Nó được báo cáo cho Intel vào ngày 24 tháng 8 năm 2022
- Downfall được trình bày tại BlackHat USA ngày 9 tháng 8 năm 2023 và USENIX Security Symposium ngày 11 tháng 8 năm 2023
- Mã tái hiện được công bố tại GitHub POC
Những điểm các nhà thiết kế bộ xử lý khác cần lưu ý
- Các bộ xử lý khác cũng có bộ nhớ SRAM dùng chung bên trong lõi như tệp thanh ghi phần cứng và fill buffer
- Các nhà sản xuất cần thiết kế cẩn trọng hơn các đơn vị bộ nhớ dùng chung để dữ liệu không bị rò rỉ giữa các miền bảo mật khác nhau
- Cần đầu tư nhiều hơn vào xác minh và kiểm thử bảo mật
Tên gọi và các lỗ hổng liên quan
- Tên gọi Downfall mang ý nghĩa làm sụp đổ các ranh giới bảo mật cơ bản của hầu hết máy tính
- Downfall có thể được xem là phần tiếp nối của các lỗ hổng rò rỉ dữ liệu CPU trước đó là Meltdown và Fallout
- Theo mạch này, Downfall một lần nữa vượt qua các biện pháp giảm thiểu trước đây
Khuyến cáo của vendor và tài liệu kỹ thuật
- Khuyến cáo bảo mật:
- MITRE: CVE-2022-40982
- Intel: INTEL-SA-00828
- AWS: AWS-2023-007
- GCP: GCP-2023-024
- Debian: CVE-2022-40982
- Ubuntu: CVE-2022-40982
- Red Hat: CVE-2022-40982
- VMware: Ứng phó với Gather Data Sampling
- Tài liệu kỹ thuật Intel:
1 bình luận
Các ý kiến trên Hacker News
Ngay cả sau cuộc tấn công Spectre ban đầu, việc các nhà nghiên cứu bên ngoài tiếp tục tìm ra các kiểu tấn công tương tự rồi nhà sản xuất chip mới vá sau đó khiến người ta thấy khá lạ
Về nguyên tắc, nhà sản xuất chip mới là chuyên gia về thực thi suy đoán, biết chính xác chip hoạt động ra sao, lại có cả bộ kiểm thử xác minh, trình mô phỏng và đặc tả nội bộ đọc được bằng máy, nên lẽ ra họ phải ở vị thế thuận lợi nhất để phát hiện
Nhà nghiên cứu bên ngoài phải dò một hộp đen và đảo ngược kỹ thuật từ các tài liệu kém hơn nhiều như bằng sáng chế, vậy mà đến tận nhiều năm sau, cá nhân hoặc nhóm bên ngoài vẫn tìm ra những lỗ hổng như thế này
Trước Spectre có thể họ chưa nghĩ đến vector tấn công kiểu này, nhưng sau khi cơ chế chung đã lộ ra, chẳng phải các nhà sản xuất chip nên tập hợp những người giỏi nhất và nói “hãy lục soát thật kỹ để tìm các kiểu tấn công khác giống Spectre” hay sao
Có thể họ đã biết hết rồi, nhưng chôn vùi với hy vọng nó không bị công khai để tránh mất mặt và tránh suy giảm hiệu năng
Với một thứ được hàng tỷ người dùng, tôi cho rằng phía bên ngoài sẽ tìm ra nhiều vấn đề, khiếm khuyết và exploit hơn cả bên tạo ra nó. Việc những vấn đề đó tồn tại tự thân không ủng hộ hay bác bỏ thêm kết luận nào về lý do đằng sau
Nhà nghiên cứu bảo mật có động cơ tìm ra thứ gì đó để xây dựng danh tiếng. Họ thường tuyên bố nó như một lỗ hổng bảo mật làm rung chuyển thế giới, dù với kẻ tấn công ngoài đời thực thì không mấy ý nghĩa
Đã từng phát hiện tấn công thực thi suy đoán trong môi trường thực tế chưa? Có lẽ là chưa. Nếu vậy, lý do để hãng chip đổ rất nhiều tiền vào đây là không mạnh
Khách hàng thực tế không bị thiệt hại, trừ khi nhà nghiên cứu bên ngoài buộc họ phải hành động và phát hành microcode mới làm chậm hiệu năng
Cũng đáng chú ý là các biện pháp giảm thiểu cho những cuộc tấn công này luôn đi kèm công tắc để tắt. Đây không phải dạng thường thấy ở bản sửa bảo mật, và trong nhiều trường hợp là vì các cuộc tấn công này không quan trọng lắm
Phần mềm chạy trên cùng một lõi vật lý hoặc cùng một CPU vật lý thường có cùng mức độ tin cậy, hoặc được sandbox đủ mạnh để không thể thực hiện cuộc tấn công
Intel chắc chắn đã làm chip “thông minh hết mức có thể”, và vì thế theo định nghĩa là không thể gỡ lỗi hoàn toàn
Điều quan trọng nữa là đây không phải lỗi. Thiết kế đang hoạt động đúng như dự định. Việc hiệu năng CPU thay đổi tùy theo đoạn mã đã chạy trước đó là điều đã được hiểu rõ, và chi phí của phương án thay thế về điện năng, hiệu năng và diện tích được đánh giá là quá lớn nên đã được chấp nhận. Đó là kỹ thuật: cân nhắc các phương án và lựa chọn
Trong trường hợp này, khi CPU trở nên đủ nhanh, một phần nhỏ của bit trên mỗi vòng lặp đã trở thành băng thông có thể bị tấn công, nhưng ngành cần có ai đó chứng minh điều đó thì mới hiểu được. Chính điều đó đã làm thay đổi phán đoán kỹ thuật
Liên kết bài viết của Intel đã chết, và liên kết đúng có vẻ là chỗ này: https://www.intel.com/content/www/us/en/developer/articles/t...
Như một lưu ý chung, liệu hiện vẫn còn nhiều đám mây chạy workload của các người dùng khác nhau trên cùng một core vật lý không? Tôi tưởng phần lớn đã đổi scheduler từ vài năm trước để ngăn rò rỉ chéo miền giữa các hyperthread rồi
Tuyên bố rằng nó ảnh hưởng đến mọi người dùng Internet nghe có vẻ phóng đại quá mức. Tôi cũng không thấy exploit dựa trên trình duyệt nào, và ngay cả nếu có tồn tại thì nó cũng chỉ ảnh hưởng đến một số cực nhỏ người dùng bị nhắm mục tiêu. Spectre đã ra đời nhiều năm rồi, không rõ đã từng có tấn công thực thi suy đoán nào được phát hiện trong môi trường thực tế chưa
Điều thú vị hơn là các lỗi thực thi suy đoán như thế này dường như vẫn liên tục có thể vá bằng microcode. Khi chúng mới xuất hiện, từng có nỗi lo rằng có thể phải loại bỏ và thay thế hàng loạt chip vật lý, nhưng trên thực tế đã bao giờ cần làm vậy chưa?
Theo tôi biết, mọi lỗi đều có thể được xử lý bằng sự kết hợp giữa thay đổi phần mềm và microcode, đôi khi chỉ phải trả một phần chi phí hiệu năng. Chưa có lỗi nào cần silicon mới. Ngoại lệ có lẽ là những trường hợp thật sự bị jailbreak không thể vá, như các phiên bản AMD SEV đời đầu
Tất nhiên cũng có loại chia sẻ như dòng T của AWS và chắc các cloud khác cũng có thứ tương tự, nhưng tôi nghĩ có thể chèn thêm thao tác “flush” giữa các người dùng để ngăn rò rỉ giữa các tenant
Dĩ nhiên rò rỉ giữa các tiến trình trong cùng một tenant vẫn là vấn đề dù ở cloud hay on-premises, và cuối cùng bạn phải quyết định mình tin đến mức nào rằng các tiến trình trên máy của mình sẽ không trở nên độc hại
Việc chạy mã từ các miền bảo mật khác nhau trên cùng một core xử lý vật lý có vẻ là không thể làm đúng, và có lẽ đã đến lúc phải dừng lại
Các trường hợp phổ biến thực ra chỉ có hai: VM và JavaScript
VM thì nên bỏ. Cần dành riêng một số core nhất định cho một VM nhất định, hoặc ít nhất cho một khách hàng nhất định
JavaScript thì khó hơn một chút
Dù theo hướng nào, không nên hy sinh hiệu năng trong trường hợp thông thường
IOPU sẽ đảm nhiệm việc điều phối các phần cứng khác trong hệ thống, và không cần hiệu năng quá cao
SPU được tối ưu cho mã vô hướng cần chạy nhanh và mã có nhiều nhánh
SPU chỉ cần bảo mật tối thiểu ở mức không cho đọc bộ nhớ tùy ý khi nạp từ RAM. Vì mỗi lần chỉ chạy một chương trình, thực thi suy đoán sẽ không còn là vấn đề
Trên hệ thống của tôi, rất ít chương trình cần nhiều năng lực xử lý, và ngay cả khi cần thì cũng chỉ theo đợt, nên có lẽ sẽ không có nhiều chuyển đổi tác vụ trên SPU
Những tấn công CPU như thế này cho thấy một hệ thống chia sẻ thời gian an toàn, nơi người dùng chạy mã máy tùy ý, không còn thực tế nữa
Chia sẻ thời gian vẫn sẽ còn trong các trường hợp mọi người tin nhau, chẳng hạn các thành viên cùng dự án dùng chung máy build
Ý tưởng rằng có thể ngăn hai chương trình chạy trên máy tính dòm ngó lẫn nhau cũng ở mức như vậy
Khuyến cáo bảo mật của Intel: https://www.intel.com/content/www/us/en/developer/articles/t...
Bản merge vào Linux kernel: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Việc chỉ bị ảnh hưởng đến thế hệ 11 khiến tôi không nghĩ rằng thời điểm lỗ hổng này được tiết lộ cho Intel đủ sớm để họ sửa trong thế hệ 12. Vậy có lẽ nó đã được khắc phục tình cờ khi họ sửa một thứ gì đó khác
Xem bài báo thì có đoạn: “Intel cho biết các CPU mới hơn như Alder Lake, Raptor Lake, Sapphire Rapids không bị ảnh hưởng. Tuy nhiên, điều này có vẻ là hệ quả phụ của một kiến trúc đã thay đổi đáng kể hơn là do cân nhắc bảo mật”
Rốt cuộc là nó đã được sửa một cách ngẫu nhiên, hoặc ít nhất exploit cụ thể này đã không còn hoạt động
Theo FAQ, người dùng đã bị phơi nhiễm với lỗ hổng này trong ít nhất 9 năm, vì các bộ xử lý bị ảnh hưởng đã tồn tại từ năm 2014
Thật đáng ngạc nhiên là một lỗ hổng như vậy không bị chú ý trong nhiều năm, rồi ai đó chỉ mất 2 tuần để viết exploit cho nó
Tham khảo bài của LWN: https://lwn.net/Articles/940783/
Trên Linux, với các CPU không có microcode đã cập nhật, AVX bị vô hiệu hóa hoàn toàn như một biện pháp giảm thiểu cho vấn đề này. Theo tôi thì khá khắc nghiệt và có lẽ sẽ cảm nhận được rõ. Giờ tôi muốn tìm hiểu xem liệu mình có thể nhận microcode đã cập nhật không
gather_data_sampling=force. Mặc định là giữ nguyên AVX và đánh dấu hệ thống là dễ bị tấn côngXem tại https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...:
Nếu chỉ định
gather_data_sampling=force, hệ thống sẽ dùng biện pháp giảm thiểu bằng microcode khi có thể; còn trên các hệ thống bị ảnh hưởng mà microcode chưa được cập nhật để bao gồm biện pháp đó, AVX sẽ bị vô hiệu hóaNhân tiện, tôi làm mảng Linux tại Intel. Rất có thể tôi đã viết hoặc chỉnh sửa các tài liệu và changelog khiến mọi người bối rối
[ 0.000000] microcode: updated early: 0x27 -> 0x28, date = 2019-11-12Tôi đang dùng Haswell. Có danh sách CPU nào nhận được microcode đã cập nhật không? Tiếc thật
Cũng đáng chú ý là GCP đã vá vấn đề này: https://cloud.google.com/support/bulletins#gcp-2023-024
Dữ liệu và instance của khách hàng AWS không bị ảnh hưởng bởi vấn đề này, và khách hàng không cần thực hiện hành động nào
AWS đã thiết kế và triển khai hạ tầng có khả năng bảo vệ trước loại vấn đề này. Các instance Amazon EC2, bao gồm Lambda, Fargate và các dịch vụ điện toán/container do AWS quản lý khác, bảo vệ dữ liệu khách hàng khỏi GDS thông qua microcode và các biện pháp giảm thiểu dựa trên phần mềm
Tác động hiệu năng là rất lớn. Có tuyên bố lên tới 50%, và nói rằng 70% các bộ xử lý Intel hiện đại bị ảnh hưởng
https://access.redhat.com/solutions/7027704
Tác động hiệu năng chỉ giới hạn ở các ứng dụng sử dụng lệnh gather do Intel Advanced Vector Extensions (AVX2 và AVX-512) cung cấp và lệnh CLWB. Tác động hiệu năng thực tế phụ thuộc vào mức độ ứng dụng sử dụng các lệnh đó
Nếu sau khi phân tích rủi ro kỹ lưỡng, người dùng quyết định tắt biện pháp giảm thiểu, chẳng hạn hệ thống không phải multi-tenant và không chạy mã không đáng tin cậy, thì có thể vô hiệu hóa biện pháp giảm thiểu
Sau khi áp dụng cập nhật microcode và kernel, có thể tắt biện pháp giảm thiểu bằng cách thêm
gather_data_samping=offvào dòng lệnh kernel. Hoặc để tắt tất cả các biện pháp giảm thiểu suy đoán thực thi của CPU, bao gồm GDS, dùngmitigations=offLuôn nên hoài nghi với các tuyên bố có chữ “tối đa”
NES có một chipset chứa trọn cả 6502 bên trong, và với giá bằng một chiếc pizza thì có thể mua được chip Rockchip ARM có lõi lai trên die. Có lẽ các nhà sản xuất chip không cần giải quyết mọi trường hợp biên mãi mãi, và có thể trả lại việc giảm thiểu tấn công kênh kề kiểu này cho chúng ta, những người đang tiêu thụ chip
Thay vì biến nó thành lựa chọn bật toàn bộ hoặc tắt toàn bộ SMT, thì sao không gửi mã không đáng tin cậy sang “lõi tệ”, rồi để khách hàng “chứng minh” rằng có thể nâng nó lên lõi có SMT?
Không ai muốn làm hỏng con chip đang chạy các tác vụ tính lương tối quan trọng mà không thứ gì khác có thể đưa lên bo mạch. Nhưng việc bị buộc phải gắn thẻ những thứ có thể chạy an toàn trên SMT, còn nếu không thì bị ràng buộc vào lõi an toàn hơn, là chấp nhận được
Một thực tập sinh hoàn toàn không biết chuyện này là gì có thể tìm kiếm, học được vector tấn công này thực sự là gì và lập kế hoạch phòng thủ
Tôi có kỳ quặc không?
Lõi hiệu năng × lõi tiết kiệm điện thì có thể
Nhưng chắc chẳng ai muốn trở thành người đề xuất lõi tin cậy × lõi không tin cậy “tệ”. Dù lợi ích có nhiều đến đâu, nó cũng sẽ bị chôn vùi trong luận điệu rằng “đang gieo rắc bất an”. Đời là vậy