GoFetch: Một cuộc tấn công side-channel mới sử dụng bộ nạp trước phụ thuộc bộ nhớ dữ liệu
(gofetch.fail)- Bộ nạp trước phụ thuộc bộ nhớ dữ liệu (DMP) có thể làm rò rỉ khóa bí mật ngay cả trong các triển khai constant-time, vì nó xử lý giá trị dữ liệu trong mã mật mã như thể đó là địa chỉ
- Trên CPU Apple m-series, khi một giá trị được tải từ bộ nhớ trông giống con trỏ, DMP sẽ cố gắng dereference nó, làm lung lay giả định lập trình constant-time về tách biệt dữ liệu và địa chỉ
- Nhóm nghiên cứu đã trình diễn trích xuất khóa end-to-end trên Apple m1 đối với OpenSSL Diffie-Hellman, giải mã RSA của Go, CRYSTALS-Kyber và CRYSTALS-Dilithium, đồng thời xác nhận hành vi DMP tương tự trên m2 và m3
- Trên m3, bit DIT có thể vô hiệu hóa DMP một cách hiệu quả, nhưng điều này không áp dụng cho m1 và m2; ngoài ra, bit cấu hình HID được phát hiện vào tháng 4/2024 hiện khó dùng ngay do thiếu hỗ trợ từ kernel macOS
- Biện pháp giảm thiểu bao gồm duy trì phần mềm mới nhất, dùng bit DIT/DOIT trên một số CPU, input blinding và tránh chia sẻ phần cứng; việc đánh giá mức độ dễ bị tấn công đòi hỏi phân tích mật mã và kiểm tra mã
Cốt lõi của cuộc tấn công GoFetch
- GoFetch là một cuộc tấn công side-channel ở mức vi kiến trúc sử dụng bộ nạp trước phụ thuộc bộ nhớ dữ liệu (DMP)
- Nó có thể trích xuất khóa bí mật ngay cả từ các triển khai mật mã được viết theo kiểu constant-time
- Các mục tiêu mà nhóm nghiên cứu đã trình diễn gồm:
- OpenSSL Diffie-Hellman Key Exchange
- Go RSA decryption
- CRYSTALS-Kyber
- CRYSTALS-Dilithium
- Bài báo và công cụ được cung cấp tại Paper, Tools
Cách DMP phá vỡ giả định constant-time
- DMP trên CPU Apple m-series được kích hoạt khi dữ liệu được tải từ bộ nhớ là một giá trị trông giống con trỏ và nó sẽ cố gắng dereference giá trị đó
- Lập trình constant-time yêu cầu tách biệt dữ liệu và địa chỉ để các nhánh, vòng lặp, truy cập bộ nhớ và chỉ số mảng không thay đổi theo giá trị bí mật
- Ngay cả khi mã của nạn nhân tuân thủ quy tắc này, DMP vẫn có thể tự tạo ra truy cập bộ nhớ phụ thuộc vào bí mật ở cấp phần cứng
- Kết quả là mã vốn phải có thời gian thực thi hằng số lại xuất hiện chênh lệch thời gian có thể quan sát được, từ đó lộ diện cho các cuộc tấn công trích xuất khóa
Quy trình tấn công
- Kẻ tấn công xây dựng đầu vào do mình chọn cho phép toán mật mã, sao cho chỉ khi đoán đúng một phần khóa bí mật thì trạng thái trung gian mới xuất hiện giá trị trông giống con trỏ
- Sau đó, chúng dùng phân tích timing của cache để kiểm tra xem DMP có thực hiện dereference hay không, từ đó xác minh phỏng đoán có đúng hay không
- Khi một phỏng đoán đúng được xác nhận, chúng tiếp tục đoán nhóm bit khóa tiếp theo theo cùng cách đó
- Với quy trình này, có thể thực hiện trích xuất khóa end-to-end trên cả triển khai mật mã cổ điển lẫn hậu lượng tử
Các bộ xử lý bị ảnh hưởng và kết quả quan sát
- Cuộc tấn công GoFetch end-to-end được thực hiện trên phần cứng dùng bộ xử lý Apple m1
- CPU m2 và m3 cũng cho thấy các mẫu kích hoạt DMP tương tự có thể bị khai thác
- Các biến thể m-series khác như m2 Pro chưa được thử nghiệm, nhưng vì dùng cùng vi kiến trúc với mẫu đơn giản hơn nên có khả năng cũng có DMP có thể bị khai thác
- Vi kiến trúc Intel 13th Gen Raptor Lake cũng có DMP
- Tuy nhiên, tiêu chí kích hoạt bị giới hạn hơn nên vững hơn trước cuộc tấn công GoFetch
Khác biệt với Augury
- DMP trên Apple m-series lần đầu được phát hiện bởi Augury
- Augury cho rằng trong một số điều kiện, DMP có thể trộn lẫn dữ liệu và địa chỉ
- Nhóm nghiên cứu GoFetch cho rằng các tiêu chí kích hoạt DMP mà Augury tổng kết là quá hạn chế
- Trong hoạt động thực tế, bất kỳ giá trị nào được tải từ bộ nhớ cũng có thể trở thành ứng viên để dereference, dẫn tới các cuộc tấn công end-to-end nhắm vào mã mật mã constant-time trong thực tế
Bối cảnh về cache và bộ nạp trước
- Các bộ xử lý hiện đại sử dụng cache để giảm độ trễ truy cập bộ nhớ
- Dữ liệu đã được truy cập trước đó sẽ còn lại trong cache, giúp các lần truy cập sau nhanh hơn
- Kẻ tấn công cùng chạy trên một máy có thể quan sát trạng thái cache dùng chung để suy ra mẫu truy cập của nạn nhân
- Bộ nạp trước thông thường dự đoán địa chỉ sẽ được truy cập tiếp theo dựa trên việc theo dõi các địa chỉ truy cập bộ nhớ trước đó
- DMP quyết định dữ liệu cần nạp bằng cách xét cả nội dung bộ nhớ nhằm xử lý các mẫu truy cập bất quy tắc như duyệt danh sách liên kết
- Hành vi này trộn dữ liệu và địa chỉ bộ nhớ ở cấp phần cứng, khiến toàn bộ ngăn xếp tính toán có thể trở nên như non-constant-time
Đánh giá tính dễ tổn thương và biện pháp giảm thiểu
- Để xác định một triển khai có dễ bị tấn công hay không, cần biết thời điểm và cách mà các giá trị trung gian có thể được tạo ra để trông giống con trỏ theo cách phụ thuộc vào bí mật
- Việc đánh giá này đòi hỏi phân tích mật mã và kiểm tra mã, vừa thủ công vừa chậm, đồng thời không thể loại trừ các phương thức tấn công khác
- Trên một số bộ xử lý, có thể vô hiệu hóa DMP
- Vào tháng 4/2024, Hector Martin (marcan) đã phát hiện bit cấu hình HID
SYS_APL_HID11_EL1[30]có thể vô hiệu hóa DMP trên CPU m1·m2- Việc đặt chicken bit này cần có hỗ trợ từ kernel
- Hiện tại macOS chưa có hỗ trợ đó
- Thông tin liên quan có trong bài viết của @marcan
- Người dùng được khuyến nghị dùng phần mềm mới nhất và cập nhật định kỳ
- Nhà phát triển thư viện mật mã có thể đặt bit DIT/DOIT trên các CPU hỗ trợ nếu có thể
- Input blinding có thể giúp tránh các giá trị trung gian do kẻ tấn công kiểm soát trong một số sơ đồ mật mã
- Tránh chia sẻ phần cứng để kẻ tấn công không thể đo việc kích hoạt DMP có thể củng cố thêm an toàn cho giao thức mật mã
Công bố và các cập nhật tiếp theo
- Nhóm nghiên cứu đã công bố kết quả cho Apple vào ngày 5/12/2023, tức 107 ngày trước khi phát hành công khai
- Tháng 8/2024, GoFetch đã giành Pwnie Award 2024 Best Cryptographic Attack
- Tháng 12/2024, một nghiên cứu tiếp theo đã reverse engineer ngữ nghĩa của Intel DMP và chỉ ra kỹ thuật có thể làm rò rỉ thông tin ngay cả khi DMP dereference con trỏ không hợp lệ
- Bài báo tiếp theo: Peek-a-Walk: Leaking Secrets via Page Walk Side Channels
- Mã nguồn có tại kho lưu trữ Peek-a-Walk trên GitHub
1 bình luận
Ý kiến trên Hacker News
Nếu đã đến thời đại có những thứ như lõi hiệu năng, có lẽ các kiến trúc hiện đại cũng cần lõi mật mã
Những lõi này nên cung cấp rõ ràng các bảo đảm liên quan đến thuật toán thời gian hằng, và không làm những việc như prefetch hay dự đoán nhánh
Nếu là một dạng giống Itanium nhưng giới hạn trong vai trò “bộ xử lý mật mã”, thì vì lược bỏ nhiều chức năng nên về nguyên tắc diện tích silicon của chính lõi cũng có lẽ không lớn
Với người triển khai mã mật mã, những vấn đề như thế này chắc mệt đến mức muốn uống rượu. Ngay cả trong tình huống tốt nhất đây đã là một cuộc chiến khó, vậy mà dù có triển khai đúng hết thì vô số tính năng hiện tại và tương lai của bộ xử lý vẫn có thể phá vỡ mã bất cứ lúc nào
Nhưng bộ đồng xử lý mật mã là một giải pháp quá mang tính phá vỡ. Phải dựng cả núi hạ tầng như chuyển sang lõi đó rồi quay lại, chia sẻ bộ nhớ, v.v.
Nghiêm trọng hơn là không thể chỉ chuyển phép nhân RSA sang lõi đó rồi coi như xong. Khóa hẳn đã được parse ở đâu đó, vậy parser cũng phải chạy trên lõi mật mã sao? Nếu nó đi vào qua mạng thì sao? Dù bảo vệ toàn bộ khóa, nếu side-channel CPU làm rò rỉ thông điệp đã được mã hóa thì có ổn không? Có thể xem là ổn vì đó không phải khóa không?
Lý do các cuộc tấn công kiểu này ít thấy trong mã không phải mật mã là vì việc tìm mục tiêu quá khác nhau tùy ứng dụng, còn trong thư viện mật mã thì mọi người đều đồng ý rằng rò rỉ khóa là điều tệ
Cuối cùng, các nhà thiết kế bộ xử lý không nên phá vỡ các giả định, và ít nhất phải nói chuyện với chúng tôi trước khi làm vậy
Đơn vị trừu tượng có lẽ nhiều khả năng sẽ ở mức luồng
https://support.apple.com/guide/security/secure-enclave-sec5...
Nhưng các kiến trúc cloud tối ưu chi phí đã nghiêng về phần cứng tiêu dùng và chiếm lĩnh thị trường CPU, nên giờ trong các ứng dụng quy mô lớn, lựa chọn thực tế cũng chỉ còn CPU tiêu dùng
Để hỗ trợ các thuật toán mới, việc thêm một số lệnh cho các phép toán nền tảng của mật mã cũng có thể là ý hay
Theo bài báo, “OpenSSL đã báo rằng tấn công side-channel cục bộ nằm ngoài mô hình đe dọa, còn nhóm Go Crypto đánh giá mức độ nghiêm trọng của cuộc tấn công này là thấp”
Kết luận cuối cùng của các cuộc tấn công side-channel kiểu này sẽ là một CPU không tối ưu hóa gì cả, và mọi lệnh đều chạy với cùng số chu kỳ trong mọi tình huống
Nhưng điều đó chắc chắn sẽ không xảy ra. Không ai muốn một CPU chậm
Nếu không thể bị khai thác từ xa thì tôi nghĩ không phải chuyện đáng lo. Tất nhiên ảo hóa cloud đa tenant thì không được
Không thực thi suy đoán, không prefetch, kiểu lõi pipeline 5 giai đoạn như trong lớp Kiến trúc máy tính 101 ấy
Có một vài nhà cung cấp cloud cho thuê thời gian tính toán trên Mac Mini gắn rack, nhưng không nhiều, và ngay cả vậy cũng dành cho workload hoặc tác vụ build rất cụ thể
Có thể đây là vấn đề với những người trả nhiều tiền cho các dịch vụ như vậy, nhưng tuyệt đại đa số thiết bị Apple Silicon sẽ không bao giờ host dịch vụ cloud
Nếu cô lập mã vào một lõi cụ thể, với giả định mọi thứ hoạt động đúng như dự định, exploit sẽ không thể xâm phạm tenant khác
Về câu “Có thể vô hiệu hóa DMP không?”, câu trả lời là “Có, nhưng chỉ trên một số bộ xử lý. Trên CPU M3, việc đặt bit DIT vô hiệu hóa DMP một cách hiệu quả, nhưng trên M1 và M2 thì không”
Chắc hẳn đâu đó phải có một chicken bit để tắt cái này chứ?
Có làm được trong Swift không, hay cần assembly?
Đọc qua thì có vẻ các thư viện như libsodium chỉ cần đặt bit vô hiệu hóa trước các phép toán mật mã nhạy cảm trên M3 trở lên
Ngoài ra có vẻ cần biết trước một số khía cạnh của khóa
Rất hay, nhưng không có vẻ thực dụng lắm
Tôi nhớ đến cuộc tấn công Augury năm 2022. Nó cũng khai thác prefetch DMP của CPU Apple Silicon
[1]: https://www.prefetchers.info
Tại sao Apple lại có nhiều backdo… lỗi thuần túy ở phần cứng như vậy?
Để trả lời thuyết âm mưu backdoor nhảm nhí đó: vì mọi người muốn CPU nhanh, nên bộ xử lý có cache và chênh lệch thời gian. Không thể vừa có thời gian hằng vừa có hiệu năng nhanh, và Apple cũng không phải công ty duy nhất có prefetch
Đây là tài liệu Apple ghi cách bật phép toán thời gian hằng cho mật mã. Trông như thể nó được thiết kế có chủ ý trong phần cứng vậy. Lạ thật nhỉ: https://developer.apple.com/documentation/xcode/writing-arm6...
Nếu viết routine mật mã, hãy dùng thư viện mật mã của nền tảng hoặc làm theo tài liệu
https://developer.apple.com/documentation/xcode/writing-arm6...
Giờ thì việc kiểm tra mã độc và trình quét virus cũng có ý nghĩa trên Mac và iPad
Kẻ tấn công phải đang chạy trên cùng phần cứng