브랜치 특권 주입: 브랜치 예측기 경쟁 상태 악용

 (comsec.ethz.ch)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Branch Privilege Injection은 Intel CPU의 분기 예측기 경쟁 상태로 약 6년간 유지된 Spectre-BTI 계열 하드웨어 방어를 다시 우회하게 만든 취약점임
  • 공격의 핵심은 분기 예측기 업데이트가 명령어 흐름과 비동기적으로 처리되며, 특정 조건에서 수십~수백 사이클 늦게 반영될 수 있다는 점임
  • 권한 전환이나 IBPB 실행 중 지연된 업데이트가 남아 있으면, 이후 잘못된 보안 도메인에 연결되어 eIBRS와 IBPB의 보안 보장이 깨질 수 있음
  • 연구진은 Ubuntu 24.04에서 기본 완화책을 모두 켠 상태로 Intel Raptor Lake 13세대에서 임의 메모리를 5.6KiB/s로 유출하는 종단 간 공격을 시연함
  • Intel의 마이크로코드 업데이트는 Alder Lake 평가에서 취약점 탐지 프리미티브를 차단했으며, 최대 2.7% 오버헤드를 보임

Branch Privilege Injection이 성립하는 조건

  • Branch Privilege Injection은 분기 대상 주입 공격, 즉 Spectre-BTI의 위력을 Intel 환경에서 다시 가능하게 만드는 공격임
  • Intel의 하드웨어 완화책은 약 6년 동안 이 유형의 공격을 막아왔지만, 이번 연구는 Intel CPU의 경쟁 상태가 그 방어를 흔들 수 있음을 보임
  • 공격은 두 가지 관찰에 기반함
    • Intel 프로세서의 분기 예측기는 명령어 흐름과 비동기적으로 업데이트됨
      • 특정 조건에서는 업데이트가 수십 또는 수백 사이클 지연됨
      • 비동기 업데이트 자체는 취약점이 아니라 기능임
    • 보안상 중요한 동작 중 분기 예측기와 명령어 흐름 사이의 동기화가 충분하지 않음
      • 사용자 모드에서 커널로, 게스트에서 하이퍼바이저로 전환되는 동안 업데이트가 아직 진행 중일 수 있음
      • IBPB 실행 중에도 진행 중인 업데이트가 남아 있을 수 있음
      • 이런 업데이트가 권한 전환 뒤 도착하면 이전 권한이 아니라 새 권한 모드에 연결됨
  • 이 취약점 종류의 이름은 Branch Predictor Race Conditions임

깨지는 완화책과 영향 범위

  • eIBRS는 Intel이 9세대 Coffee Lake Refresh 이후 모든 프로세서에 도입한 Spectre-BTI 완화책임
    • 간접 분기 예측을 서로 다른 보안 도메인별로 분리하는 것이 목표임
    • 각 예측을 생성된 도메인과 연결하고, 이후 현재 도메인의 예측만 사용하도록 설계됨
    • 권한 전환 중 진행 중인 업데이트가 새 보안 도메인에 연결되면 이 연결을 조작할 수 있음
  • IBPB는 같은 하드웨어 보안 도메인 안에서 샌드박스나 서로 신뢰하지 않는 가상 머신을 분리할 때 쓰이는 메커니즘임
    • 모든 간접 분기 예측을 무효화하는 기능을 제공함
    • 진행 중인 업데이트는 IBPB로 플러시되지 않아, 무효화 이후에도 분기 예측기에 저장될 수 있음
  • 영향 범위에는 세대와 아키텍처별 차이가 있음
    • Intel 9세대 Coffee Lake Refresh 이후 모든 프로세서가 Branch Privilege Injection의 영향을 받음
    • IBPB 우회 예측은 7세대 Kaby Lake까지 거슬러 관찰됨
    • 평가한 AMD와 ARM 시스템에서는 문제가 발견되지 않음
    • 개념증명 공격은 Linux용으로 만들었지만, 근본 문제는 하드웨어에 있으므로 영향받는 하드웨어에서 실행되는 운영체제는 영향을 받음

완화책, 성능 비용, 공개 자료

  • 최신 운영체제와 BIOS 업데이트 설치가 권고됨
  • Intel은 영향받는 프로세서용 마이크로코드 업데이트를 개발했고, 연구진은 Alder Lake에서 이를 평가함
    • 마이크로코드 완화책은 취약점 탐지 프리미티브를 차단함
    • Alder Lake에서 최대 2.7% 오버헤드를 보임
  • 소프트웨어 대안 완화책도 평가됨
    • Coffee Lake Refresh에서는 1.6% 오버헤드
    • Rocket Lake에서는 8.3% 오버헤드
  • 자세한 기술 내용은 논문에서 확인할 수 있음
  • Branch Privilege Injection 논문은 USENIX Security 2025에서 발표될 예정이며, Black Hat USA 2025 발표도 예정됨
  • 공격과 실험 소스 코드는 github에 공개됨

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 연구진 블로그 글: https://comsec.ethz.ch/research/microarch/branch-privilege-i...
    논문: https://comsec.ethz.ch/wp-content/files/bprc_sec25.pdf

    • 영향 예시: 시간이 지나면 전체 메모리 내용을 읽을 수 있고, 오류를 반복적으로 유발해 초당 5000바이트가 넘는 읽기 속도를 낼 수 있다고 Rüegge가 설명함
      공격 상황에서는 결국 CPU 메모리 전체의 정보가 잘못된 손에 들어가는 건 시간문제가 됨
    • 제목 URL을 그 블로그 글로 바꿔주면 좋겠음. 보도자료는 쓸모없다 못해 해로운 수준임

  • 좋은 글임. 요약하면 분기 예측기 업데이트가 분기 명령이 은퇴(retire)한 뒤 한참 후로 미뤄질 수 있음
    그렇지 않다면 분기 명령 은퇴가 더 오래 걸릴 테니 말이 됨. 디스패치 직렬화 명령도 예측기 상태의 대기 중 업데이트 때문에 파이프라인을 멈추지 않는 듯하고, 이는 “분기 명령 결과 커밋”과 “예측 결과 커밋”을 이미 구분했기 때문에 자연스러움
    권한 변경 명령도 대기 중 업데이트 때문에 파이프라인을 멈추지 않는데, 예측을 만들 때와 커밋할 때의 권한 수준이 일관된다고 보장할 수 있을 때만 타당함. 아니면 한 권한 수준의 코드가 만든 예측이 다른 권한 수준에서 쓰이는 상태에 커밋될 수 있음
    아마 파이프라인 안에서 현재 권한 수준이 단일하고 명확한 값이 아니라서 어려운 문제일 수도 있음

  • Kaveh Razavi를 보니 반가움. 예전에 암스테르담 Vrije Universiteit에서 가르쳤고, Hardware Security 과목이 이런 내용을 깊게 다뤄서 정말 멋졌음

    • 몇 년 전에 이 과목과 Vrije의 악성코드 관련 다른 과목을 찾아봤는데, 당시에는 공개 자료가 거의 없었음
      공식 녹화나 노트가 온라인에 있는지 궁금함

  • 이게 방금 공개된 Training Solo 공격과 어떤 관련이 있는지 아는 사람? https://www.vusec.net/projects/training-solo/

    • 둘 다 Spectre V2를 악용하지만 방식이 다름
      Training Solo는 커널에 진입해 권한 수준을 바꾼 뒤 “자기 학습”으로 분기를 disclosure gadget 쪽으로 오예측하게 만들어 메모리를 누출함
      Branch predictor race conditions는 학습된 분기 예측기 업데이트가 아직 처리 중일 때 커널에 진입해, 그 업데이트가 잘못된 권한 수준에 연결되게 함. 다시 이를 이용해 커널의 분기를 disclosure gadget으로 돌리고 메모리를 누출함

  • CPU 분기 예측기가 버퍼 경계와 코드 권한 수준을 확인할 정보를 바로 쓸 수 있었다면 이런 문제는 훨씬 막기 쉬웠을 것임
    하지만 C 프로그래머들의 차가운 손에서 void*를 빼앗고 포인터에 중요한 정보를 보강하기 전까지는 그런 일은 없을 듯함

    • 그게 어떻게 도움이 된다는 건지 모르겠음. 이건 소프트웨어 추상화가 아니라 하드웨어 문제라서 “포인터”를 바꿔도 트랜지스터에는 아무 영향이 없음
      원하는 걸 하려면 모든 로드/스토어가 경계 정보를 저장하는 일종의 “증강 주소”를 거쳐야 하는 하드웨어 아키텍처가 필요함
      즉 80286 세그먼테이션을 요구하는 셈인데, 이미 있었고 원하는 걸 해주지 못했음. 이유는 그 세그먼트 디스크립터도 소프트웨어가 제대로 로드해야 하기 때문임. 소프트웨어 입장에서는 결국 “그냥 포인터”라서 같은 실수에 취약함
    • 원하는 건 CHERI임
    • 문제의 범위를 더 잘 이해할 수도 있음. 취약점이 있다고 해서 곧바로 공격으로 이어지는 건 아님
      추측 실행의 경우 그 취약점을 실제로 뭔가에 쓰려면 말도 안 될 정도의 사전 준비가 필요함. 실제로 쓸 수 있는 거의 유일한 방식은 해당 컴퓨터에 직접 접근해서 저수준 코드를 실행하는 경우임. 브라우저에서 돌아가는 JS 코드만으로 임의의 비밀을 누출하는 식은 아님
      전담 민간 조직이나 국가 지원 조직이 필요한 연구와 표적화를 할 만큼 가치 있는 시스템이라면, 애초에 허가되지 않은 임의 코드가 실행되지 못하게 하는 체계가 있어야 함
      개인적으로는 성능 향상이 실제로 체감돼서 모든 완화책을 꺼둠

  • Intel 보안 권고: https://www.intel.com/content/www/us/en/security-center/advi...

  • AMD 하드웨어에도 비슷한 빈틈이 있는지 궁금함. 추측 실행은 공유 프로세서 공간에서 패치하기 매우 어려운 취약점처럼 보여서, AMD가 어떻게 피해 왔는지 궁금함

    • 연구진 블로그에 따르면 Branch Privilege Injection은 Intel 외 CPU에는 영향을 주지 않음
      평가한 AMD와 ARM 시스템에서는 문제가 발견되지 않았다고 함
      출처: https://comsec.ethz.ch/research/microarch/branch-privilege-i...
    • 짧게 말하면 AMD가 “피해 온” 게 아님. 추측 실행 부채널은 하나의 취약점이 아니라 취약점 계열임
      이 특정 취약점은 Meltdown처럼 Intel 전용으로 보이지만, AMD도 원래 Spectre에는 취약했음
    • 엄밀히 말하면 추측 실행 자체가 취약점은 아님. 요즘 모든 고성능 CPU에 필요한 메커니즘이고, 여기서 “요즘”은 대략 세기 전환기부터임
      다만 추측 실행 엔진은 복잡해서 버그와 취약점이 매우 널리 퍼져 있음
      AMD와 ARM에도 비슷한 버그가 있을 가능성이 큼. Intel에서 이런 버그들이 얼마나 오래 발견되지 않았는지 생각해보면 됨
      안타깝게도 진짜 해결책은 현대 시스템에서 실행되는 코드를 격리할 수 없다는 사실을 인정하는 것인데, 이는 일부 매우 부유한 회사들의 사업 모델에는 치명적일 수 있음
    • 이 특정 취약점의 해법은 직관적으로 보임. 분기 예측기 업데이트를 큐에 넣을 때 현재 권한 수준을 스냅샷으로 저장하고, 그 업데이트가 프로세서 내부 버퍼를 흐르는 동안 스냅샷도 함께 들고 가면 됨
      소프트웨어에서 생길 법한 문제와 같은 해법 아닌가?

  • “이런 빈틈을 막으려면 프로세서 마이크로코드의 특수 업데이트가 필요하다. BIOS나 운영체제 업데이트로 가능하므로 Windows의 최신 누적 업데이트 중 하나로 PC에 설치돼야 한다”라고 하는데, 왜 Windows만 언급함? Linux 사용자는?

    • Intel은 Linux용 마이크로코드 업데이트를 여기서 배포함: https://github.com/intel/Intel-Linux-Processor-Microcode-Dat...
      배포판들은 여기서 가져와 자동 배포하도록 구성돼 있음
      다만 이 특정 완화책이 이미 들어갔는지 확인하려면 무엇을 봐야 하는지는 잘 모름
    • Linux 커널은 오래전부터 마이크로코드 로딩 지원(CONFIG_MICROCODE / CONFIG_MICROCODE_INTEL)이 있었음
      다만 Intel이 배포판 관리자들이 패키지를 업데이트할 수 있도록 필요한 마이크로코드 파일을 공개해야 하고, 그다음 시스템 업데이트에 포함될 것임

  • Intel이 회복할 방법이 있는지 궁금함. 시장에 그럴듯한 제품이 없고, 연구개발에는 시간이 오래 걸리며, 파운드리는 경쟁사보다 뒤처져 계속 손실의 원천임
    게다가 x86은 ARM 하드웨어에 점점 밀려나고 있고, 이제 중국발 RISC-V도 커지고 있음. 물론 미국 반도체 관점도 있음. 특히 코로나 때 문제를 겪은 뒤, 미국이 Intel 같은 핵심 제조사가 무너지게 놔둘까?

    • Intel은 기술 블로그들이 떠드는 것만큼 큰 위기에 있지는 않음
      상황이 좋지는 않지만 선정주의가 우스울 정도임
      게이머는 Intel 제품 사용자 중 몇 퍼센트에 불과한데, 그쪽 얘기만 가장 많이 들림. 데이터센터 주문 한두 건이 Intel이 1년에 파는 게이밍 CPU 전체보다 큼. Intel은 여전히 데이터센터 시장에서 잘 버티고 있음
      여기에 Intel은 기업용 노트북 시장도 여전히 지배하고 있고, 이 시장 역시 게이머 시장보다 꽤 큰 폭으로 큼
    • Intel은 여전히 x86 시장 점유율이 70%를 훨씬 넘음. 활주로가 길게 남아 있음
      Arm은 작년 데이터센터 시장 점유율이 15%에 불과했고, Windows 시장에서도 아직 큰 진전을 이루지 못했음
    • 기대치에 달린 듯함. 회사로서 괜찮을까? 그렇다고 봄. 역사상 여러 시점에서 그랬던 것만큼 두드러진 존재가 될까? 그렇지는 않을 듯함
      제품과 별개로 주주/사업 관점에서는 요즘 재무 성과가 최종 제품을 점점 덜 반영한다고 봐서 따로 생각하려 하는데, Intel은 대마불사에 가깝다고 봄
    • Apple, Nvidia 같은 회사들이 Intel 파운드리를 쓰려고 한다는 내용을 읽은 것 같은데, 열등하다면 왜 그러겠음? 아니면 다른 얘기였나?

  • 제대로 이해했는지 확인하고 싶은데, 현재 시점에는 주요 운영체제 모두 이 문제를 완화하거나 관련 마이크로코드를 적용하는 패치가 나와 있는 건가?

    • 맞음. 엠바고 해제일이 5월 13일, 오늘임
답변달기