ZenHammer: Tấn công Rowhammer nhắm vào các nền tảng dựa trên AMD Zen

 (comsec.ethz.ch)
1 điểm bởi GN⁺ 2024-03-26 | 1 bình luận | Chia sẻ qua WhatsApp
  • Bit flip Rowhammer xảy ra ngay cả trên các hệ thống DDR4 AMD Zen 2 và Zen 3 đã áp dụng biện pháp giảm thiểu TRR, cho thấy nền tảng AMD cũng có thể trở thành bề mặt tấn công thực tế
  • Nhóm nghiên cứu đã đảo ngược kỹ thuật các hàm địa chỉ DRAM bí mật bằng kỹ thuật DRAMA được điều chỉnh cho AMD, và xác nhận rằng cần xử lý offset địa chỉ vật lý do cơ chế ánh xạ lại địa chỉ hệ thống
  • Fuzzer ZenHammer gây ra bit flip trên 7 thiết bị ở Zen 2 và 6 thiết bị ở Zen 3 trong số 10 thiết bị DDR4, bao gồm Samsung, Micron và SK Hynix; các thiết bị Zen 3 cho kết quả dễ bị tấn công hơn Intel Coffee Lake
  • Các tấn công hiện có vào bảng trang, làm hỏng khóa công khai RSA-2048 và sudoers.so lần lượt có thể cấu hình trên 7/6/4 thiết bị, với thời gian trung bình để tìm bit flip có thể khai thác là 164/267/209 giây
  • Trong đánh giá DDR5 trên Zen 4, khoảng 42.000 bit flip xảy ra trên 1 trong 10 thiết bị, nhưng thất bại trên 9 thiết bị còn lại, cho thấy DDR5 cần nghiên cứu thêm về mẫu tấn công

Bit flip Rowhammer cũng xảy ra trên AMD Zen

  • ZenHammer gây ra bit flip Rowhammer trên các hệ thống AMD Zen 2 và Zen 3 trong thiết bị DDR4 đã áp dụng biện pháp giảm thiểu TRR
  • Xác nhận rằng hệ thống AMD cũng có thể có lỗ hổng Rowhammer, tương tự hệ thống Intel
  • Với thị phần CPU desktop x86 của AMD vào khoảng 36%, bề mặt tấn công không hề nhỏ
  • Thiết bị DRAM một khi đã triển khai thì khó sửa đổi dễ dàng, và các nghiên cứu trước đây đã cho thấy tấn công Rowhammer có thể thực tế trong nhiều môi trường

Đảo ngược hàm địa chỉ DRAM của AMD và tối ưu hóa hammering

  • Áp dụng kỹ thuật DRAMA cho hệ thống AMD để đảo ngược kỹ thuật các hàm địa chỉ DRAM bí mật
  • Thay đổi các routine đo thời gian để thu được kết quả ổn định hơn
  • Do cơ chế ánh xạ lại địa chỉ hệ thống, cần áp dụng offset địa chỉ vật lý trước khi khôi phục hàm địa chỉ DRAM; nhờ đó khôi phục hoàn chỉnh hàm địa chỉ
  • Chỉ sử dụng các hàm địa chỉ đã khôi phục thì số bit flip bị hạn chế
    • Trên Zen 2, bit flip chỉ được xác nhận ở 5 trong 10 thiết bị
    • Trên Zen 3, bit flip không được xác nhận ở thiết bị nào trong 10 thiết bị

Đồng bộ refresh và chuỗi lệnh

  • Giống các nghiên cứu trước như SMASH và Blacksmith, đồng bộ refresh là yếu tố quan trọng để gây ra bit flip
  • Trên AMD, phương pháp thực hiện đo thời gian liên tục trên các hàng không lặp lại tỏ ra hiệu quả cho việc đồng bộ refresh chính xác và đáng tin cậy
  • Trên các hệ thống AMD Zen+/3, tỉ lệ kích hoạt của mẫu Rowhammer không đồng nhất thấp hơn đáng kể so với Intel Coffee Lake
  • Chuỗi lệnh hammering tối ưu là dùng lệnh tải thông thường MOV và CLFLUSHOPT để flush aggressor khỏi cache, theo kiểu “scatter” flush ngay sau khi truy cập aggressor
  • Khác với Zen 2, trên Zen 3 không cần fence tường minh sau khi flush
  • Loại fence và chính sách lập lịch fence cũng ảnh hưởng đến kết quả; nhóm nghiên cứu đề xuất 6 chính sách nhận dạng mẫu và né cache, rồi thử nghiệm 6 giờ cho từng thiết bị
    • Trên phần lớn thiết bị Zen 2, SP_none là tối ưu
    • Trong hầu hết trường hợp trên Zen 3, SP_pair phù hợp hơn

Kết quả đánh giá DDR4 và khả năng khai thác

  • Đánh giá được thực hiện trên 10 thiết bị DRAM DDR4, bao gồm Samsung, Micron và SK Hynix
  • Fuzzer ZenHammer được chạy 3 giờ cho mỗi tổ hợp giữa từng loại fence mfence, sfence và từng chính sách lập lịch fence
  • Sau mỗi lần chạy, minisweep được thực hiện trên phạm vi 4MiB với tất cả mẫu tìm được để xác định mẫu tối ưu, rồi sweep mẫu tối ưu của chính sách tối ưu trên vùng bộ nhớ liên tục 256MB
  • Kết quả là bit flip xảy ra trên 7 thiết bị ở Zen 2 và 6 thiết bị ở Zen 3 trong số 10 thiết bị DRAM DDR4
  • Khả năng khai thác bit flip được đánh giá bằng ba tấn công từ nghiên cứu trước
    • Tấn công page frame number của mục nhập bảng trang để pivot sang trang bảng trang do kẻ tấn công kiểm soát
    • Tấn công khóa công khai RSA-2048 cho phép khôi phục khóa riêng liên quan dùng trong xác thực SSH host
    • Tấn công logic xác minh mật khẩu của thư viện sudoers.so, cho phép giành quyền root
  • Các tấn công hiện có lần lượt có thể cấu hình trên 7/6/4 thiết bị, với thời gian trung bình để tìm bit flip có thể khai thác là 164/267/209 giây

Đánh giá DDR5, mã nguồn công khai và lịch trình công bố

  • Nhóm cũng đảo ngược kỹ thuật hàm DRAM DDR5 trên AMD Zen 4 và đánh giá 10 thiết bị DDR5
  • ZenHammer gây ra khoảng 42.000 bit flip trên 1 trong 10 thiết bị DDR5
  • Đây là trường hợp đầu tiên được công khai báo cáo về bit flip DDR5 trên hệ thống thương mại phổ thông
  • Trên 9 thiết bị DDR5 còn lại không xảy ra bit flip, nên cần nghiên cứu thêm để tìm các mẫu hiệu quả hơn cho thiết bị DDR5
  • Toàn bộ chi tiết có trong bài báo sẽ được trình bày tại USENIX Security 2024 vào tháng 8/2024
  • Mã fuzzer ZenHammer có trên GitHub, có thể dùng để đánh giá liệu thiết bị DRAM có xảy ra bit flip trên CPU AMD Zen 2/3/4 hay không
  • Nhóm cho rằng Rowhammer là vấn đề đã biết trên toàn ngành nên không cần quy trình công bố thông thường, nhưng đã thông báo cho AMD vào 26/02/2024 và theo yêu cầu của AMD đã không công bố cho đến 25/03/2024
  • Trang này từng vô tình được đưa online trong một thời gian ngắn vào 21/03/2024

Các hạn chế thực tiễn trong FAQ

  • Lý do hệ thống AMD trước đây ít được đề cập là trong nghiên cứu Rowhammer ban đầu, số bit flip trên hệ thống Intel lớn hơn nhiều; các nghiên cứu tiếp theo cũng chủ yếu tập trung vào Intel; và thông tin về vi kiến trúc CPU Intel được biết đến nhiều hơn AMD
  • Trong 10 thiết bị DDR4, bit flip không xảy ra trên 3 thiết bị với Zen 2 và 4 thiết bị với Zen 3, nhưng vì số bit flip của các thiết bị này trên Intel Coffee Lake cũng ít, nhóm cho rằng việc tinh chỉnh fuzzer thêm có thể làm lộ ra bit flip
  • Lý do số thiết bị đánh giá bị giới hạn ở 10 là số lượng thiết bị AMD Zen 2/3 trong phòng thí nghiệm có hạn và một số thí nghiệm mất nhiều thời gian; tập con ngẫu nhiên này bao gồm thiết bị của cả 3 nhà cung cấp DRAM
  • Về lý do JEDEC vẫn chưa khắc phục vấn đề, nhóm giải thích rằng việc giải quyết Rowhammer là khó nhưng không bất khả thi, như các nghiên cứu trước ProTRR và REGA đã cho thấy
  • Nghiên cứu trước về DDR3 cho thấy ECC không ngăn được Rowhammer; do số bit flip trên các thiết bị DDR4 hiện nay lớn hơn, ECC được đánh giá chỉ làm việc khai thác khó hơn chứ không bảo vệ hoàn toàn
  • Cách tăng gấp đôi tần suất refresh có overhead hiệu năng và tăng tiêu thụ điện năng; trong các nghiên cứu trước như Mutlu et al. và Frigo et al., đây được xem là giải pháp yếu, không cung cấp khả năng bảo vệ hoàn toàn

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-03-26
Ý kiến trên Hacker News

  • Tôi là đồng tác giả ban đầu của khai thác Rowhammer. ECC nhìn chung vẫn rất hiệu quả trong việc biến vấn đề này từ một vấn đề bảo mật thành một vấn đề độ tin cậy
    Nếu bạn là chủ sở hữu máy chủ cá nhân, giả sử máy chủ có ECC và bạn có thể nhận ra việc máy bị dừng do lỗi ECC không thể sửa, thì tác động về bảo mật không lớn
    Tuy nhiên, nếu bạn là nhà cung cấp đám mây cung cấp VM trên host đa tenant, mô hình đe dọa có thể khác
    Dù thế nào cũng nên tránh các máy không có ECC. TRR đã là một biện pháp phòng thủ thất bại ngay từ khi Rowhammer mới được biết đến, và chừng nào tính kinh tế trong sản xuất DRAM chưa thay đổi thì bit flip trong DRAM sẽ không biến mất

    • Nếu có thể thì tôi muốn dùng bộ nhớ ECC. Trước đây tôi dùng TR 2920x có ECC, nhưng hiện đang dùng Ryzen 7950x không ECC
      Ryzen chỉ hỗ trợ ECC unbuffered, vốn chậm hơn hoặc đắt hơn bộ nhớ không ECC cùng dung lượng, hoặc cả hai
      Dòng Threadripper mới nhất hỗ trợ Registered ECC, nhưng với người dùng gia đình như tôi thì chi phí, số luồng và số lane PCIe đều quá dư thừa
    • Nếu “chừng nào tính kinh tế trong sản xuất DRAM chưa thay đổi thì bit flip trong DRAM sẽ không biến mất”, thì đó có vẻ là đủ lý do để bắt buộc bộ nhớ ECC trên mọi máy tính
      Rủi ro bảo mật quá lớn và mọi thứ đã tích hợp quá sâu, nên khó có thể trì hoãn thay đổi này. Ngay cả game thủ dùng máy tính thuần chơi game cũng sẽ để thông tin quan trọng trên máy đó; thật khó hiểu vì sao đến giờ thay đổi này vẫn chưa diễn ra
    • Tôi nghe nói DDR2 miễn nhiễm với Rowhammer, nhưng không rõ có đúng vậy không, hay chỉ là chưa ai nghiên cứu kỹ
      Tôi cũng thắc mắc liệu thứ thật sự miễn nhiễm có chỉ là SRAM hay không
    • AMD giờ cũng đang đi theo kiểu phân khúc thị trường của Intel, vô hiệu hóa ECC trên phần lớn CPU Ryzen
      Chỉ Pro và Threadripper là được đảm bảo, còn một số Ryzen desktop chỉ dùng được trên một số bo mạch chủ nhất định
    • Có vài câu hỏi mà tôi chưa tìm được câu trả lời thỏa đáng trong các bài báo trước đây. Các bộ máy patrol read hiện đại có được dẫn hướng bằng mẫu truy cập bộ nhớ để đối phó với kiểu tấn công Rowhammer không?
      Để đi trước một cách an toàn các bit flip do Rowhammer gây ra, bộ máy patrol read cần quét DRAM quyết liệt đến mức nào?
      Nếu có word ECC lớn hơn kiểu 64+8 truyền thống và khả năng sửa lỗi đa bit, liệu cục diện có thay đổi đủ để tạo ra hệ thống đáng tin cậy hơn ngay cả với DRAM có điểm yếu theo mẫu hay không?

  • Cách diễn đạt kiểu “ECC không ngăn được Rowhammer” rất dễ gây hiểu lầm. Bài báo được trích cũng nói rằng “ngay cả khi phát hiện ECC được sử dụng đúng cách, 0,65%~7,42% tổng số bit flip vẫn gây hư hỏng âm thầm… trong cấu hình AMD-1, lỗi không thể sửa sẽ làm hệ thống crash”
    Để có được một bit flip có thể khai thác, kẻ tấn công phải gây ra hàng chục lần máy bị dừng. Hàng chục lần máy bị dừng không phải là chuyện có thể không bị phát hiện
    Việc chỉ ra phản ứng tệ hại của JEDEC trước Rowhammer là tốt, nhưng không nên đánh giá thấp ECC như một giải pháp ngắn hạn

    • Tôi thắc mắc liệu đội vận hành quản lý hệ thống có quy trình để xác định hiện tượng đó là tấn công, chứ không chỉ là phần cứng không ổn định hay không
    • Nếu nhắm vào một máy cụ thể thì đúng là vậy, nhưng nếu rải exploit kiểu shotgun lên hàng nghìn máy, bạn vẫn có thể có được botnet. Quy mô chỉ nhỏ hơn một chút thôi
    • Một trong những lý do tôi mua ECC cho máy desktop ở nhà là để phòng Rowhammer
      Đó là nền tảng Zen2 TR, nên khi đọc câu đó tim tôi thót lại trong giây lát. Cách diễn đạt khá dễ gây hiểu lầm
    • Tôi thắc mắc có khuyến nghị nào về thiết bị client có bộ nhớ ECC không

  • Tôi thắc mắc liệu các vấn đề bảo mật phần cứng như Rowhammer, Spectre, Meltdown có phải là rủi ro thực tế với người bình thường hay không
    Tôi hiểu Spectre và Meltdown là vấn đề đối với các tấn công như thoát VM, tức là việc kỹ sư AWS phải lo chứ dường như không phải chuyện của người dùng cá nhân

    • Giải pháp là tắt JavaScript và không chạy ứng dụng không đáng tin cậy
      Và vì đã cắt đứt với xã hội hiện đại rồi, hãy vào một cabin trong rừng và tự cung tự cấp là xong
    • Từ góc nhìn của một nhà nghiên cứu bảo mật phần cứng nói thẳng, các lỗ hổng bị khai thác thực tế ảnh hưởng đến người dùng trung bình tầm thường hơn nhiều và phần lớn là dựa trên phần mềm
    • Mọi người nên cài một tiện ích mở rộng dạng danh sách cho phép script nào đó, và chỉ chạy JavaScript của các trang web mà mình thật sự tin tưởng
      Cá nhân tôi thích NoScript. Trên Chrome thì tôi không rõ nên chọn gì
      Ngoài ra thì… bạn cũng đâu thường xuyên chạy chương trình tùy ý từ internet phải không?
      Những loại lỗi này mới chỉ là phần nổi. Phần cứng hiện đại quá phức tạp nên khó tin rằng ta có thể tìm ra hết
    • Rowhammer cũng có triển khai JavaScript có thể chạy trong trình duyệt: https://github.com/IAIK/rowhammerjs
    • Từ góc độ bảo mật, trình duyệt web là một dạng VM hypervisor, và mỗi website coi như có VM riêng của nó
      Vì vậy mọi người đều có thể bị ảnh hưởng

  • Trước đây tôi chỉ hiểu rất mơ hồ về các cuộc tấn công lật bit DDR, nhưng đọc bài báo Hammertime gốc thì thấy thật ra khá dễ đọc
    Tôi vẫn chưa đọc hết, nhưng nó giải thích rất dễ hiểu. Tôi đã nghe cụm “lật bit” vô số lần nhưng chưa từng hiểu đúng, đọc cái này thì mới bắt đầu nắm được
    https://comsec.ethz.ch/wp-content/files/hammertime_raid18.pd...
    Cảm giác như vừa học một buổi nhập môn điện-điện tử. Tôi hoàn toàn không biết chuyện này thực sự liên quan đến lỗi sản xuất phần cứng
    Cái tên Rowhammer lúc đó cũng mới được giải thích. Có lẽ tôi quá tụt hậu và đây là điều ai cũng biết rồi
    “Do mật độ cực cao của các mảng DRAM hiện đại, những lỗi sản xuất nhỏ có thể tạo ra liên kết điện yếu giữa các ô liền kề. Kết hợp với điện dung cực nhỏ của các ô này, mỗi khi một hàng DRAM được đọc trong một bank, các ô nhớ ở hàng lân cận sẽ mất một lượng điện tích nhỏ. Nếu điều này xảy ra đủ thường xuyên giữa hai chu kỳ refresh, ô bị ảnh hưởng có thể mất đủ điện tích để giá trị bit được lưu bị đảo, hiện tượng này được gọi là ‘disturbance error’ hoặc gần đây là Rowhammer”

    • Chỉ nhìn vào phần giải thích này thì nghe như đây là bản chất không thể tránh khỏi khi sản xuất DRAM, nhưng không phải vậy
      Là do các nhà sản xuất DRAM đã đẩy các giới hạn đến mức cực đoan. Đó là vì lợi nhuận
      Không khác gì Ford khi cho rằng chi phí dàn xếp các vụ kiện liên quan đến thương tích và tử vong của Pinto thấp hơn chi phí sửa thiết kế xe

  • Tôi thắc mắc liệu Secure Memory Encryption có giúp ích gì trong trường hợp này không
    https://www.amd.com/en/developer/sev.html

    • Có giúp, nhưng có thể đánh đổi rất nhiều về độ ổn định
      Chỉ một lần lật bit cũng có thể trở thành lỗi nghiêm trọng

  • Tôi biết quá ít về bảo mật phần cứng, nên thắc mắc liệu đây có phải là một trong vô số lỗ hổng tất yếu sinh ra từ tối ưu hóa CPU, và trong thực tế thuộc loại khó khả thi hay không

    • Có thể nói là còn tệ hơn. Chuyện này phát sinh từ vật lý của DRAM
      Nó xảy ra ở tầng thấp hơn rất nhiều so với các trường hợp biên của những tính năng làm rò rỉ thông tin qua kênh kề
      Dữ liệu được lưu dưới dạng các điện tích nhỏ trong một lưới; nếu đảo nhiều điểm lưới gần đó, có thể khiến một phần điện tích rò về phía điện tích mục tiêu
      Điện tích càng nhỏ và càng gần nhau thì tấn công Rowhammer càng dễ. Đồng thời, điện tích càng nhỏ và càng gần nhau thì RAM càng nhanh, rẻ, dày đặc và hiệu quả hơn
      Có các biện pháp giảm thiểu, nhưng mọi thứ đã bị đẩy đến giới hạn rồi
    • Đây là vấn đề của RAM, không phải vấn đề của CPU

  • Tôi thắc mắc liệu nó có còn hoạt động khi bật mã hóa toàn bộ bộ nhớ, poisoning và XOR địa chỉ không

    • Nếu có mã hóa bộ nhớ, nó sẽ không dẫn đến việc chiếm quyền hệ thống mà chỉ làm hệ thống crash
      Vì vậy dùng mã hóa bộ nhớ sẽ an toàn hơn

  • Nếu “ZenHammer không thể gây ra flip trên 9 trong 10 thiết bị… cần nghiên cứu thêm để tìm mẫu hiệu quả hơn với thiết bị DDR5”, thì có vẻ DDR5 vẫn còn chút thời gian
    Không biết có ai biết điều này có ảnh hưởng đến LPDDR5x không

    • Giao diện DRAM được tách khá rõ khỏi chính mảng bộ nhớ
      Vì vậy việc là DDR5, LPDDR5(x), GDDR6(x) hay HBM3(e) không phải là câu hỏi cốt lõi
      Điều quan trọng là chi tiết triển khai do nhà sản xuất quyết định, chẳng hạn ECC on-die

  • Zen 2 và 3 được nhắc đến, nhưng tôi thắc mắc có thông tin gì về Zen 1 không
    Hay là nó cũng áp dụng y như vậy?