ZenHammer: AMD Zen 기반 플랫폼을 겨냥한 Rowhammer 공격

 (comsec.ethz.ch)
1P by GN⁺ | ★ favorite | 댓글 1개
  • TRR 완화가 적용된 AMD Zen 2·Zen 3 DDR4 시스템에서도 Rowhammer 비트 플립이 발생해, AMD 플랫폼 역시 실질적인 공격 표면이 될 수 있음
  • 연구팀은 AMD에 맞춘 DRAMA 기법으로 비밀 DRAM 주소 함수를 역공학했고, 시스템 주소 재매핑 때문에 물리 주소 오프셋 처리가 필요함을 확인함
  • ZenHammer fuzzer는 Samsung, Micron, SK Hynix를 포함한 10개 DDR4 장치 중 Zen 2에서 7개, Zen 3에서 6개에서 비트 플립을 유발했으며, Zen 3 장치는 Intel Coffee Lake보다 더 취약한 결과를 보임
  • 기존 페이지 테이블, RSA-2048 공개키 손상, sudoers.so 공격은 각각 7/6/4개 장치에서 구성 가능했고, 악용 가능한 비트 플립을 찾는 평균 시간은 164/267/209초였음
  • Zen 4의 DDR5 평가에서는 10개 중 1개 장치에서 약 42,000개 비트 플립이 발생했지만, 나머지 9개에서는 실패해 DDR5에는 추가 패턴 연구가 필요함

AMD Zen에서도 발생한 Rowhammer 비트 플립

  • ZenHammer는 TRR 완화가 적용된 DDR4 장치에서 AMD Zen 2와 Zen 3 시스템의 Rowhammer 비트 플립을 유발함
  • AMD 시스템도 Intel 시스템과 마찬가지로 Rowhammer 취약성을 가질 수 있음이 확인됨
  • AMD의 x86 데스크톱 CPU 시장 점유율이 약 36% 라는 점에서 공격 표면이 작지 않음
  • DRAM 장치는 이미 배포된 뒤 쉽게 수정하기 어렵고, 이전 연구들은 Rowhammer 공격이 여러 환경에서 실용적일 수 있음을 보였음

AMD DRAM 주소 함수 역공학과 해머링 최적화

  • AMD 시스템에 맞게 DRAMA 기법을 적용해 비밀 DRAM 주소 함수를 역공학함
  • 더 안정적인 결과를 얻기 위해 타이밍 루틴을 변경함
  • 시스템 주소 재매핑 때문에 DRAM 주소 함수를 복구하기 전에 물리 주소 오프셋을 적용해야 했고, 이를 통해 주소 함수를 완전히 복구함
  • 복구한 주소 함수만 사용하는 방식으로는 비트 플립 수가 제한적이었음
    • Zen 2에서는 10개 장치 중 5개에서만 비트 플립이 확인됨
    • Zen 3에서는 10개 장치 중 0개에서 비트 플립이 확인됨

리프레시 동기화와 명령 시퀀스

  • 이전 연구인 SMASH와 Blacksmith처럼 리프레시 동기화가 비트 플립 유발에 중요한 요소였음
  • AMD에서는 반복되지 않는 행을 대상으로 연속 타이밍 측정을 수행하는 방식이 정밀하고 신뢰성 있는 리프레시 동기화에 효과적이었음
  • AMD Zen+/3 시스템에서는 비균일 Rowhammer 패턴의 활성화율이 Intel Coffee Lake보다 크게 낮았음
  • 최적 해머링 명령 시퀀스는 일반 로드 MOV와 CLFLUSHOPT를 사용해 aggressor를 캐시에서 플러시하고, aggressor 접근 직후 플러시하는 “scatter” 스타일이었음
  • Zen 2와 달리 Zen 3에서는 플러시 뒤 명시적 fence가 필요하지 않았음
  • fence 유형과 fence 스케줄링 정책도 결과에 영향을 줬고, 연구팀은 6가지 패턴 인식·캐시 회피 정책을 제안해 장치별로 6시간씩 테스트함
    • Zen 2의 대부분 장치에서는 SP_none이 최적이었음
    • Zen 3의 대부분 경우에는 SP_pair가 더 적합했음

DDR4 평가 결과와 악용 가능성

  • 평가는 Samsung, Micron, SK Hynix를 포함한 10개 DDR4 DRAM 장치를 대상으로 진행됨
  • ZenHammer fuzzer는 각 fence 유형인 mfence, sfence와 각 fence 스케줄링 정책 조합으로 3시간씩 실행됨
  • 각 실행 뒤에는 발견된 모든 패턴으로 4MiB 범위에서 minisweep을 수행해 최적 패턴을 정하고, 최적 정책의 최적 패턴을 256MB 연속 메모리 영역에 sweep함
  • 그 결과 DDR4 DRAM 장치 10개 중 Zen 2에서 7개, Zen 3에서 6개에서 비트 플립이 발생함
  • 비트 플립의 악용 가능성은 기존 연구의 세 가지 공격으로 평가됨
    • 페이지 테이블 엔트리의 page frame number를 공격해 공격자 제어 페이지 테이블 페이지로 피벗하는 공격
    • SSH 호스트 인증에 쓰이는 관련 개인키를 복구할 수 있게 하는 RSA-2048 공개키 공격
    • root 권한 획득을 가능하게 하는 sudoers.so 라이브러리의 비밀번호 검증 로직 공격
  • 기존 공격은 각각 7/6/4개 장치에서 구성 가능했고, 악용 가능한 비트 플립을 찾는 평균 시간은 164/267/209초였음

DDR5 평가, 공개 코드, 발표 일정

  • AMD Zen 4에서 DDR5 DRAM 함수도 역공학하고 10개 DDR5 장치를 평가함
  • ZenHammer는 10개 중 1개 DDR5 장치에서 약 42,000개 비트 플립을 유발함
  • 이는 일반 상용 시스템에서 DDR5 비트 플립을 공개적으로 보고한 첫 사례임
  • 나머지 9개 DDR5 장치에서는 비트 플립이 발생하지 않아, DDR5 장치에는 더 효과적인 패턴을 찾기 위한 추가 연구가 필요함
  • 전체 세부 내용은 2024년 8월 USENIX Security 2024에 발표될 논문에 포함됨
  • ZenHammer fuzzer 코드는 GitHub에서 제공되며, AMD Zen 2/3/4 CPU에서 DRAM 장치의 비트 플립 여부를 평가하는 데 사용할 수 있음
  • Rowhammer는 알려진 업계 전반의 문제라 일반적인 공개 절차가 필요하지 않다고 판단했지만, AMD에는 2024년 2월 26일 알렸고 AMD 요청에 따라 2024년 3월 25일까지 공개하지 않았음
  • 이 페이지는 실수로 2024년 3월 21일 잠시 온라인에 공개됐음

FAQ의 실무적 제한 사항

  • AMD 시스템이 이전에 적게 다뤄진 이유는 원래 Rowhammer 연구에서 Intel 시스템의 비트 플립 수가 훨씬 많았고, 후속 연구도 주로 Intel에 집중했으며, Intel CPU 마이크로아키텍처 정보가 AMD보다 더 많이 알려져 있었기 때문임
  • 10개 DDR4 장치 중 Zen 2에서는 3개, Zen 3에서는 4개에서 비트 플립이 발생하지 않았지만, Intel Coffee Lake에서도 이 장치들의 비트 플립 수가 적었기 때문에 fuzzer를 더 조정하면 비트 플립이 드러날 수 있다고 봄
  • 평가 장치가 10개로 제한된 이유는 연구실의 AMD Zen 2/3 장비 수가 제한적이고 일부 실험 시간이 길었기 때문이며, 무작위 하위 집합에는 3대 DRAM 공급업체 장치가 모두 포함됨
  • JEDEC이 아직 문제를 고치지 못한 이유에 대해, Rowhammer 해결은 어렵지만 불가능하지 않으며 이전 연구 ProTRR와 REGA에서 이를 보였다고 설명함
  • DDR3에 대한 이전 연구는 ECC가 Rowhammer를 막지 못함을 보였고, 현재 DDR4 장치의 비트 플립 수가 더 많기 때문에 ECC는 완전한 보호가 아니라 악용을 더 어렵게 만드는 수준으로 판단됨
  • 리프레시율을 두 배로 올리는 방식은 성능 오버헤드와 전력 소비 증가가 있으며, Mutlu et al.과 Frigo et al. 등의 이전 연구에서 완전한 보호를 제공하지 못하는 약한 해법으로 나타남

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 원래 Rowhammer 익스플로잇 공동 저자임. ECC는 이 문제를 대체로 보안 이슈에서 신뢰성 이슈로 바꾸는 데 여전히 매우 효과적임
    개인 서버 소유자라면, 서버에 ECC가 있고 수정 불가능한 ECC 오류로 인한 머신 중단을 알아차릴 수 있다고 기대한다면 보안상 영향은 크지 않음
    다만 다중 테넌트 호스트에서 VM을 제공하는 클라우드 사업자라면 위협 모델이 달라질 수 있음
    어느 쪽이든 ECC 없는 머신은 피해야 함. TRR은 Rowhammer가 막 알려졌을 때도 이미 실패한 방어였고, DRAM 제조 경제성이 바뀌지 않는 한 DRAM 비트 플립은 사라지지 않음

    • 가능하다면 ECC 메모리를 쓰고 싶음. 예전에는 ECC가 있는 TR 2920x를 썼지만 지금은 비-ECC Ryzen 7950x를 사용 중임
      Ryzen이 지원하는 건 언버퍼드 ECC뿐인데, 같은 용량의 비-ECC 메모리보다 느리거나 비싸거나 둘 다임
      최신 Threadripper 라인업은 Registered ECC를 지원하지만, 나 같은 가정 사용자에게는 비용·스레드·PCIe 레인 모두 과함
    • “DRAM 제조 경제성이 바뀌지 않는 한 DRAM 비트 플립은 사라지지 않는다”면, 모든 컴퓨터에 ECC 메모리 의무화가 필요하다는 논거로 충분해 보임
      보안 위험이 너무 크고 모든 것이 너무 통합되어 있어서 이 변화를 미루기 어렵다. 순수 게임용 컴퓨터를 쓰는 게이머도 중요한 정보를 그 머신에 둘 텐데, 지금까지 이 변화가 없었던 게 이해되지 않음
    • DDR2는 Rowhammer에 면역이라는 얘기를 들었는데 실제로 그런지, 아니면 아무도 제대로 조사하지 않아서 그런지 궁금함
      정말로 면역인 건 SRAM뿐인지도 궁금함
    • AMD도 이제 Intel식 시장 세분화를 따라가면서 대부분의 Ryzen CPU에서 ECC를 비활성화하고 있음
      Pro와 Threadripper만 보장되고, 일부 데스크톱 Ryzen은 일부 메인보드에서만 가능함
    • 기존 논문들에서 만족스러운 답을 못 찾은 질문들이 있음. 최신 순찰 읽기 엔진은 Rowhammer식 공격에 대응하도록 메모리 접근 패턴의 안내를 받는가?
      Rowhammer로 유발되는 비트 플립을 안전하게 앞서가려면 순찰 읽기 엔진이 DRAM을 얼마나 공격적으로 스캔해야 하는가?
      전통적인 64+8보다 큰 ECC 워드와 다중 비트 오류 정정이 있으면, 패턴 취약성이 있는 DRAM으로도 더 신뢰성 높은 시스템을 만들 수 있을 만큼 판이 바뀌는가?

  • “ECC가 Rowhammer를 막지 못한다”는 식의 표현은 매우 오해를 부름. 인용한 논문도 “ECC 감지가 올바르게 사용될 때도 전체 비트 플립의 0.65%~7.42%가 조용한 손상을 일으킨다… AMD-1 구성에서는 수정 불가능한 오류가 시스템을 크래시시킨다”고 말함
    공격자가 악용 가능한 비트 플립 하나를 얻으려면 수십 번의 머신 중단을 일으켜야 함. 수십 번의 머신 중단은 안 들킬 수 있는 일이 아님
    JEDEC의 Rowhammer 대응이 형편없다는 점을 짚은 건 좋지만, 단기 해법으로서 ECC를 과소평가해서는 안 됨

    • 시스템을 관리하는 운영팀이 그 현상을 단순히 불안정한 하드웨어가 아니라 공격이라고 판단할 수 있는 절차가 있는지 궁금함
    • 특정 머신을 노리는 경우라면 그렇겠지만, 수천 대에 익스플로잇을 산탄총처럼 뿌리면 여전히 봇넷은 얻을 수 있음. 규모가 좀 작아질 뿐임
    • 집 데스크톱에 ECC를 산 이유 중 하나가 Rowhammer 방어였음
      Zen2 TR 플랫폼인데, 해당 문구를 보고 순간 심장이 철렁했음. 꽤 오해를 부르는 표현임
    • ECC 메모리가 있는 클라이언트 기기 추천이 있는지 궁금함

  • 보통 사람에게 Rowhammer, Spectre, Meltdown 같은 하드웨어 보안 이슈가 실제 위험인지 궁금함
    Spectre와 Meltdown은 VM 탈출 같은 공격에 문제가 되는 것으로 이해했는데, AWS 엔지니어가 신경 쓸 일이지 개인 사용자에게는 아닌 것처럼 보였음

    • 해법은 JavaScript를 끄고 신뢰할 수 없는 앱을 실행하지 않는 것임
      그리고 현대 사회와 단절됐으니 숲속 오두막으로 가서 자급자족하면 됨
    • 냉정하게 말하는 하드웨어 보안 연구자 입장에서, 평균 사용자에게 영향을 주는 실제 악용 취약점은 훨씬 평범하고 대부분 소프트웨어 기반임
    • 모두가 어떤 형태로든 스크립트 허용 목록 확장 기능을 설치하고, 정말 신뢰하는 웹사이트의 JavaScript만 실행해야 함
      개인적으로는 NoScript를 좋아함. Chrome에서는 무엇을 골라야 할지 잘 모르겠음
      그 외에는… 인터넷에서 임의 프로그램을 자주 실행하지는 않지 않나?
      이런 종류의 버그는 아직 표면만 긁은 수준임. 현대 하드웨어는 너무 복잡해서 전부 찾아낼 수 있다고 믿기 어려움
    • Rowhammer는 브라우저에서 실행 가능한 JavaScript 구현도 있음: https://github.com/IAIK/rowhammerjs
    • 보안 관점에서 웹 브라우저는 일종의 VM 하이퍼바이저이고, 각 웹사이트가 자기 VM을 가진 셈임
      그래서 모든 사람이 영향을 받을 수 있음

  • DDR 비트 플립 공격들을 아주 어렴풋이만 이해하고 있었는데, 원래의 Hammertime 논문을 보니 실제로 읽기 쉬움
    아직 전부 읽지는 않았지만 이해하기 좋게 잘 풀어줌. 비트 플립이라는 말을 수없이 들었지만 제대로 이해한 적이 없었는데, 이걸 보고 감이 왔음
    https://comsec.ethz.ch/wp-content/files/hammertime_raid18.pd...
    전기전자 입문 수업 하나를 들은 느낌임. 이게 실제 하드웨어 제조 결함과 관련 있다는 걸 전혀 몰랐음
    Rowhammer라는 이름도 그제야 설명됨. 내가 너무 뒤처져 있었고 다들 아는 내용일 수도 있음
    “현대 DRAM 배열의 극단적인 밀도 때문에 작은 제조 결함이 인접 셀 사이의 약한 전기적 결합을 만들 수 있다. 이런 셀의 극히 작은 정전용량과 결합되면, DRAM 행이 뱅크에서 읽힐 때마다 인접 행의 메모리 셀은 소량의 전하를 잃는다. 두 리프레시 주기 사이에 충분히 자주 발생하면 영향을 받은 셀은 저장된 비트 값이 뒤집힐 만큼 전하를 잃을 수 있으며, 이를 ‘disturbance error’ 또는 최근에는 Rowhammer라고 부른다”

    • 이 설명만 보면 DRAM을 만들 때 피할 수 없는 본질처럼 들리지만 그렇지 않음
      DRAM 제조사들이 한계를 극단적으로 밀어붙였기 때문임. 이윤 추구임
      부상과 사망 관련 Pinto 소송 합의 비용이 차량 설계 수정 비용보다 낮다고 판단한 Ford와 다르지 않음

  • Secure Memory Encryption이 여기에 도움이 되는지 궁금함
    https://www.amd.com/en/developer/sev.html

    • 도움이 되긴 하지만 안정성을 크게 잃을 수 있음
      비트 플립 하나만으로도 치명적 오류가 될 수 있음

  • 하드웨어 보안을 너무 모르는데, 이게 CPU 최적화에서 생기는 수많은 필연적 취약점 중 하나이고 현실에서는 실현 가능성이 낮은 부류인지 궁금함

    • 오히려 더 나쁘다고 볼 수 있음. 이건 DRAM의 물리에서 생김
      부채널로 정보를 새게 하는 기능의 경계 사례보다 훨씬 낮은 수준에서 발생함
      데이터는 격자 안의 작은 전하로 저장되는데, 근처 격자점을 많이 뒤집으면 목표 전하 쪽으로 일부 전하가 새게 만들 수 있음
      전하가 작고 서로 가까울수록 Rowhammer 공격은 쉬워짐. 동시에 전하가 작고 가까울수록 RAM은 더 빠르고 싸고 조밀하고 효율적이 됨
      완화책은 있지만 이미 한계까지 밀어붙여져 있음
    • 이건 RAM 문제이지 CPU 문제가 아님

  • 전체 메모리 암호화, 포이즈닝, 주소 XOR를 켜도 이게 동작하는지 궁금함

    • 메모리 암호화가 있으면 시스템 장악으로 이어지지는 않고 시스템 크래시가 날 뿐임
      그래서 메모리 암호화를 쓰면 더 안전함

  • “ZenHammer가 10개 장치 중 9개에서는 플립을 유발하지 못했다… DDR5 장치에 더 효과적인 패턴을 찾으려면 추가 연구가 필요하다”면, DDR5에는 아직 약간의 시간이 남은 셈 같음
    이것이 LPDDR5x에도 영향을 주는지 아는 사람이 있는지 궁금함

    • DRAM 인터페이스는 메모리 배열 자체와 꽤 잘 분리되어 있음
      그래서 DDR5, LPDDR5(x), GDDR6(x), HBM3(e) 중 무엇인지가 핵심 질문은 아님
      중요한 것은 온다이 ECC 같은 제조사 재량의 구현 세부사항임

  • Zen 2와 3은 언급되는데 Zen 1에 대한 정보가 있는지 궁금함
    그냥 똑같이 적용되는 건가?

답변달기