- Branch Privilege Injection là một lỗ hổng khiến các cơ chế phòng vệ phần cứng thuộc họ Spectre-BTI, vốn đã được duy trì khoảng 6 năm, lại có thể bị vượt qua do điều kiện tranh chấp trong bộ dự đoán nhánh của CPU Intel
- Điểm cốt lõi của cuộc tấn công là việc cập nhật bộ dự đoán nhánh được xử lý bất đồng bộ với luồng lệnh, và trong một số điều kiện nhất định có thể được phản ánh trễ hàng chục đến hàng trăm chu kỳ
- Nếu các bản cập nhật bị trì hoãn vẫn còn trong quá trình chuyển đổi đặc quyền hoặc khi thực thi IBPB, chúng có thể được gắn với miền bảo mật sai sau đó, phá vỡ các bảo đảm an toàn của eIBRS và IBPB
- Các nhà nghiên cứu đã trình diễn một cuộc tấn công end-to-end trên Intel Raptor Lake thế hệ 13, trong Ubuntu 24.04 với tất cả biện pháp giảm thiểu mặc định được bật, làm rò rỉ bộ nhớ tùy ý ở tốc độ 5,6KiB/s
- Bản cập nhật microcode của Intel đã chặn primitive phát hiện lỗ hổng trong đánh giá trên Alder Lake, với overhead tối đa 2,7%
Điều kiện để Branch Privilege Injection xảy ra
- Branch Privilege Injection là một cuộc tấn công tiêm mục tiêu nhánh, tức là cuộc tấn công khiến sức mạnh của Spectre-BTI có thể khả thi trở lại trong môi trường Intel
- Các biện pháp giảm thiểu phần cứng của Intel đã ngăn chặn kiểu tấn công này trong khoảng 6 năm, nhưng nghiên cứu này cho thấy điều kiện tranh chấp trong CPU Intel có thể làm lung lay lớp phòng vệ đó
- Cuộc tấn công dựa trên hai quan sát
- Bộ dự đoán nhánh của bộ xử lý Intel được cập nhật bất đồng bộ với luồng lệnh
- Trong một số điều kiện nhất định, cập nhật có thể bị trễ hàng chục hoặc hàng trăm chu kỳ
- Bản thân cập nhật bất đồng bộ không phải là lỗ hổng mà là một tính năng
- Không có đủ sự đồng bộ hóa giữa bộ dự đoán nhánh và luồng lệnh trong các thao tác quan trọng về bảo mật
- Trong quá trình chuyển từ user mode sang kernel, hoặc từ guest sang hypervisor, cập nhật có thể vẫn đang diễn ra
- Ngay cả khi thực thi IBPB, vẫn có thể còn các cập nhật đang diễn ra
- Nếu những cập nhật này đến sau khi chuyển đổi đặc quyền, chúng sẽ được gắn với chế độ đặc quyền mới thay vì đặc quyền trước đó
- Bộ dự đoán nhánh của bộ xử lý Intel được cập nhật bất đồng bộ với luồng lệnh
- Tên của loại lỗ hổng này là Branch Predictor Race Conditions
Các biện pháp giảm thiểu bị phá vỡ và phạm vi ảnh hưởng
- eIBRS là biện pháp giảm thiểu Spectre-BTI mà Intel đã đưa vào tất cả bộ xử lý kể từ Coffee Lake Refresh thế hệ 9
- Mục tiêu là tách biệt dự đoán nhánh gián tiếp theo từng miền bảo mật khác nhau
- Nó được thiết kế để gắn mỗi dự đoán với miền đã tạo ra dự đoán đó, và sau đó chỉ sử dụng các dự đoán của miền hiện tại
- Nếu cập nhật đang diễn ra trong quá trình chuyển đổi đặc quyền được gắn với miền bảo mật mới, liên kết này có thể bị thao túng
- IBPB là cơ chế được dùng để tách biệt sandbox hoặc các máy ảo không tin cậy lẫn nhau trong cùng một miền bảo mật phần cứng
- Nó cung cấp chức năng vô hiệu hóa mọi dự đoán nhánh gián tiếp
- Các cập nhật đang diễn ra không bị IBPB flush, nên vẫn có thể được lưu vào bộ dự đoán nhánh ngay cả sau khi vô hiệu hóa
- Phạm vi ảnh hưởng có khác biệt theo thế hệ và kiến trúc
- Tất cả bộ xử lý Intel kể từ Coffee Lake Refresh thế hệ 9 đều bị ảnh hưởng bởi Branch Privilege Injection
- Việc vượt qua IBPB trong dự đoán đã được quan sát từ Kaby Lake thế hệ 7 trở về sau
- Không phát hiện vấn đề trên các hệ thống AMD và ARM được đánh giá
- Tấn công proof-of-concept được tạo cho Linux, nhưng vấn đề gốc nằm ở phần cứng, nên các hệ điều hành chạy trên phần cứng bị ảnh hưởng đều chịu tác động
Biện pháp giảm thiểu, chi phí hiệu năng và tài liệu công khai
- Khuyến nghị cài đặt các bản cập nhật hệ điều hành và BIOS mới nhất
- Intel đã phát triển bản cập nhật microcode cho các bộ xử lý bị ảnh hưởng, và các nhà nghiên cứu đã đánh giá bản cập nhật này trên Alder Lake
- Biện pháp giảm thiểu bằng microcode chặn primitive phát hiện lỗ hổng
- Trên Alder Lake, overhead tối đa là 2,7%
- Các biện pháp giảm thiểu thay thế bằng phần mềm cũng đã được đánh giá
- Trên Coffee Lake Refresh, overhead là 1,6%
- Trên Rocket Lake, overhead là 8,3%
- Có thể xem nội dung kỹ thuật chi tiết trong bài báo
- Bài báo về Branch Privilege Injection dự kiến được trình bày tại USENIX Security 2025, và cũng dự kiến có phần trình bày tại Black Hat USA 2025
- Mã nguồn của cuộc tấn công và các thử nghiệm được công bố trên github
1 bình luận
Ý kiến trên Hacker News
Bài viết blog của nhóm nghiên cứu: https://comsec.ethz.ch/research/microarch/branch-privilege-i...
Bài báo: https://comsec.ethz.ch/wp-content/files/bprc_sec25.pdf
Trong kịch bản tấn công, việc toàn bộ thông tin trong bộ nhớ CPU cuối cùng rơi vào tay kẻ xấu chỉ còn là vấn đề thời gian
Bài viết hay. Tóm lại, cập nhật bộ dự đoán nhánh có thể bị trì hoãn rất lâu sau khi lệnh rẽ nhánh đã nghỉ hưu (retire)
Điều này hợp lý, vì nếu không thì việc nghỉ hưu của lệnh rẽ nhánh sẽ mất lâu hơn. Có vẻ các lệnh tuần tự hóa dispatch cũng không dừng pipeline do các cập nhật trạng thái bộ dự đoán đang chờ xử lý, và điều này là tự nhiên vì đã có sự phân biệt giữa “commit kết quả lệnh rẽ nhánh” và “commit kết quả dự đoán”
Các lệnh thay đổi đặc quyền cũng không dừng pipeline vì các cập nhật đang chờ xử lý, nhưng điều đó chỉ hợp lý khi có thể bảo đảm mức đặc quyền tại thời điểm tạo dự đoán và tại thời điểm commit là nhất quán. Nếu không, dự đoán do mã ở một mức đặc quyền tạo ra có thể được commit vào trạng thái được dùng ở một mức đặc quyền khác
Có lẽ đây là vấn đề khó vì bên trong pipeline, mức đặc quyền hiện tại không phải là một giá trị đơn nhất và rõ ràng
Rất vui khi thấy Kaveh Razavi. Trước đây ông ấy từng giảng dạy ở Vrije Universiteit Amsterdam, và môn Hardware Security đào sâu vào những nội dung kiểu này, thật sự rất tuyệt
Không biết các bản ghi hình chính thức hoặc ghi chú có được đưa lên mạng không
Có ai biết chuyện này liên quan thế nào đến tấn công Training Solo vừa được công bố không? https://www.vusec.net/projects/training-solo/
Training Solo đi vào kernel, thay đổi mức đặc quyền, rồi dùng “tự huấn luyện” để khiến nhánh bị dự đoán sai sang disclosure gadget và làm rò rỉ bộ nhớ
Branch predictor race conditions thì đi vào kernel khi bản cập nhật bộ dự đoán nhánh đã được huấn luyện vẫn đang được xử lý, khiến bản cập nhật đó bị gắn với mức đặc quyền sai. Sau đó lại lợi dụng điều này để chuyển hướng nhánh của kernel sang disclosure gadget và làm rò rỉ bộ nhớ
Nếu bộ dự đoán nhánh của CPU có thể dùng ngay thông tin để kiểm tra ranh giới buffer và mức đặc quyền của mã, thì những vấn đề như thế này sẽ dễ ngăn chặn hơn nhiều
Nhưng có lẽ điều đó sẽ không xảy ra cho đến khi chúng ta giằng được
void*khỏi bàn tay lạnh lẽo của các lập trình viên C và bổ sung thông tin quan trọng cho con trỏĐể làm điều bạn muốn, cần một kiến trúc phần cứng trong đó mọi load/store đều đi qua một dạng “địa chỉ tăng cường” lưu thông tin ranh giới
Nói cách khác là đang đòi phân đoạn 80286, thứ đã từng tồn tại và đã không làm được điều mong muốn. Lý do là các segment descriptor đó cũng phải được phần mềm nạp đúng cách. Từ góc nhìn phần mềm, cuối cùng nó vẫn chỉ là “con trỏ”, nên vẫn dễ mắc cùng loại sai lầm
Với thực thi suy đoán, để thực sự dùng lỗ hổng đó vào việc gì đó cần một lượng chuẩn bị phi lý. Gần như cách duy nhất có thể dùng trong thực tế là có quyền truy cập trực tiếp vào máy tính đó và chạy mã cấp thấp. Không phải kiểu chỉ bằng mã JS chạy trong trình duyệt là có thể rò rỉ bí mật tùy ý
Nếu đó là hệ thống đủ giá trị để các tổ chức tư nhân chuyên trách hoặc tổ chức được nhà nước hậu thuẫn bỏ công nghiên cứu và nhắm mục tiêu, thì ngay từ đầu hệ thống đó nên có cơ chế không cho chạy mã tùy ý chưa được cho phép
Cá nhân tôi tắt hết mọi biện pháp giảm thiểu vì hiệu năng cải thiện thật sự cảm nhận được
Khuyến cáo bảo mật của Intel: https://www.intel.com/content/www/us/en/security-center/advi...
Tôi tò mò liệu phần cứng AMD có lỗ hổng tương tự hay không. Thực thi suy đoán có vẻ là một dạng lỗ hổng rất khó vá trong không gian bộ xử lý dùng chung, nên tôi thắc mắc AMD đã tránh được như thế nào
Họ nói không phát hiện vấn đề trên các hệ thống AMD và ARM được đánh giá
Nguồn: https://comsec.ethz.ch/research/microarch/branch-privilege-i...
Lỗ hổng cụ thể này, giống Meltdown, có vẻ chỉ dành riêng cho Intel, nhưng AMD vốn cũng dễ bị Spectre
Tuy nhiên bộ máy thực thi suy đoán rất phức tạp nên lỗi và lỗ hổng lan rộng ở mức đáng kể
Rất có khả năng AMD và ARM cũng có các lỗi tương tự. Chỉ cần nghĩ xem những lỗi như vậy ở Intel đã không bị phát hiện trong bao lâu
Đáng tiếc là giải pháp thật sự là thừa nhận rằng không thể cô lập mã chạy trên các hệ thống hiện đại, điều này có thể chí mạng đối với mô hình kinh doanh của một số công ty rất giàu có
Chẳng phải đây là cùng một kiểu vấn đề và cách giải có thể xuất hiện trong phần mềm sao?
Có nói rằng “để bịt các lỗ hổng kiểu này cần một bản cập nhật đặc biệt cho microcode của bộ xử lý. Có thể thực hiện qua bản cập nhật BIOS hoặc hệ điều hành, nên nó sẽ được cài lên PC qua một trong các bản cập nhật tích lũy mới nhất của Windows”, nhưng tại sao chỉ nhắc đến Windows? Người dùng Linux thì sao?
Các bản phân phối được cấu hình để lấy từ đây và tự động phân phối
Tuy nhiên tôi không rõ cần xem gì để xác nhận liệu biện pháp giảm thiểu cụ thể này đã được đưa vào hay chưa
CONFIG_MICROCODE/CONFIG_MICROCODE_INTEL) từ lâuTuy nhiên Intel phải công bố các tệp microcode cần thiết để các quản trị viên bản phân phối có thể cập nhật gói, rồi sau đó chúng sẽ được đưa vào các bản cập nhật hệ thống
Tôi tự hỏi liệu Intel có cách nào phục hồi không. Họ không có sản phẩm nào thật sự thuyết phục trên thị trường, R&D thì mất nhiều thời gian, còn mảng foundry thì tụt hậu so với đối thủ và tiếp tục là nguồn gây lỗ
Thêm nữa x86 ngày càng bị phần cứng ARM lấn át, và giờ RISC-V từ Trung Quốc cũng đang lớn mạnh. Tất nhiên còn có góc nhìn bán dẫn của Mỹ. Đặc biệt sau khi gặp vấn đề trong thời Covid, liệu Mỹ có để một nhà sản xuất then chốt như Intel sụp đổ không?
Tình hình không tốt, nhưng mức độ giật gân thì buồn cười
Game thủ chỉ chiếm vài phần trăm người dùng sản phẩm Intel, nhưng lại là nhóm được nghe nói đến nhiều nhất. Một hoặc hai đơn hàng trung tâm dữ liệu còn lớn hơn toàn bộ số CPU gaming mà Intel bán trong một năm. Intel vẫn đang trụ vững trong thị trường trung tâm dữ liệu
Ngoài ra Intel vẫn thống trị thị trường laptop doanh nghiệp, và thị trường này cũng lớn hơn thị trường game thủ một khoảng khá lớn
Năm ngoái Arm chỉ có 15% thị phần trung tâm dữ liệu, và cũng chưa đạt tiến triển lớn trong thị trường Windows
Tách khỏi sản phẩm, từ góc nhìn cổ đông/kinh doanh, tôi cho rằng kết quả tài chính ngày nay ngày càng ít phản ánh sản phẩm cuối cùng, nên tôi cố xem riêng; Intel thì gần như thuộc diện quá lớn để sụp đổ
Tôi muốn kiểm tra xem mình hiểu đúng không: tính đến hiện tại, có phải tất cả các hệ điều hành lớn đều đã có bản vá để giảm thiểu vấn đề này hoặc áp dụng microcode liên quan rồi không?