▲

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

 (comsec.ethz.ch)
1P by GN⁺ 20시간전 | ★ favorite | 댓글 1개
  • 브랜치 예측기의 경쟁 상태로 인해 Intel CPU에서 새로운 보안 취약점인 Branch Privilege Injection이 발견됨
  • 이 공격은 비동기적 업데이트와 보안 도메인 간의 불충분한 동기화로 인해 가능해짐
  • eIBRS와 IBPB 등 기존의 하드웨어 완화책이 경쟁 상태에서 무력화됨
  • Intel은 마이크로코드 업데이트로 해당 취약점을 완화하며, 성능 저하가 있음
  • 취약점은 9세대 이후 모든 Intel CPU에 영향을 주며, 운영체제와 관계없이 발생함

Branch Privilege Injection 공격 개요

  • Branch Privilege Injection은 Spectre-BTI 계열 브랜치 타겟 인젝션 공격을 새로운 방식으로 부활시킨 보안 취약점임
  • Intel CPU에서 하드웨어 차원의 Spectre 방어가 6년간 효과를 발휘했으나, 이번 연구를 통해 경쟁 상태(race condition) 에 의한 우회 가능함이 증명됨
  • 브랜치 예측기는 인스트럭션 스트림과 비동기적으로 동작하여 특정 상황에서 10~100 수십/수백 사이클 지연된 업데이트가 발생함
  • 브랜치 예측기의 업데이트가 진행 중일 때 특권 전환(예: 유저-커널, 게스트-하이퍼바이저)이나 IBPB가 동작하면, 해당 업데이트가 새로운 권한 모드에 잘못 연관되는 문제가 발생함
  • 이를 Branch Predictor Race Condition으로 명명하며, 이로 인해 민감한 메모리 정보 유출이 가능해짐

공격 시연 및 영향

  • 이 공격법으로 Ubuntu 24.04(최신 패치 및 기본 완화 적용)에서 임의의 메모리 유출 속도가 5.6KiB/s에 달함
  • Intel Raptor Lake(13세대) CPU에서 공격 성공 영상 시연이 있음

영향을 받는 완화책

  • eIBRS: 9세대(Coffee Lake Refresh) 이후 Intel CPU에 도입된 보안 메커니즘으로, 간접 분기 예측을 보안 도메인별로 분리함.
  • IBPB: eIBRS가 하드웨어 보안 도메인 간 공격만 막기에, IBPB가 불신 가상머신 등 추가 보안 구간을 위해 전체 간접 브랜치 예측을 무효화하는 기능임
  • 양쪽 모두 지정된 환경에서 보안 기본값으로 권고되는 완화책임

Branch Predictor Race Condition 상세 분석

  • 브랜치 예측기에서 경쟁 상태 가 생기면 eIBRS 및 IBPB의 보안 보장이 무효화됨
  • 인스트럭션 실행 도중 특권 전환이 이루어질 때, 진행 중인 브랜치 예측 업데이트가 새로운 보안 도메인에 잘못 귀속됨
  • IBPB를 수행해도, 진행 중이던 예측 업데이트가 플러시되지 않고 예측기에 남아 보안 문제가 발생함

Branch Predictor Race Condition에 대한 완화책

  • Intel은 취약한 프로세서를 위해 마이크로코드 업데이트 를 개발했으며, Alder Lake에서 실험적으로 공격 차단을 확인함
  • 해당 완화책 적용 시 Alder Lake에서 최대 2.7%의 성능 저하 발생함
  • 소프트웨어적 대안 완화 전략도 실험 결과 1.6%(Coffee Lake Refresh)~8.3%(Rocket Lake) 성능 오버헤드가 측정됨
  • 자세한 내용은 논문에서 추가 정보 제공됨

추가 자료

  • Branch Privilege Injection 핵심 연구 논문은 USENIX Security 2025에서 발표 예정임
  • Black Hat USA 2025에서 취약점 탐지 및 익스플로잇 중심 발표가 있을 예정임
  • 공격 및 실험 소스코드는 github에서 공개됨

FAQ

1. 내 컴퓨터가 영향을 받는가?

  • 9세대(Coffee Lake Refresh) 이후의 모든 Intel 프로세서가 Branch Privilege Injection의 영향을 받음
  • IBPB 무력화 현상은 7세대(Kaby Lake) 제품까지에서도 확인됨

2. 비-Intel CPU도 영향을 받는가?

  • 분석 결과 AMD 및 ARM 시스템에서는 이 문제가 발견되지 않았음

3. Linux만 영향을 받는가?

  • PoC는 Linux용이나, 근본적 문제는 하드웨어에 존재함
  • 해당 하드웨어에서 작동하는 모든 운영체제가 취약함

4. 대응 방안은?

  • 운영체제 및 BIOS의 최신 업데이트를 설치하는 조치가 권장됨
▲
GN⁺ 20시간전  [-]
Hacker News 의견

  • 하버드에서 발행한 글에서, 존에게 불운하게도 브랜치들이 사탄과 양자역학과 거래를 맺어서 미래 세대 프로세서에 해로운 마법을 걸었음이라는 재치 있는 비유를 들며, 이 마법은 '스케일링으로 인한 전압 누수'나 '낭비되는 열 증가' 같은 이름으로 남았음

  • James Mickens의 글이 항상 재미있음이라는 감상과 함께, 보안을 담당하는 Mossad가 HTTPS 같은 걸 신경 안 쓴다는 농담을 인용하며, 그들은 데이터가 필요하면 아예 드론으로 핸드폰을 우라늄 모조품으로 바꿔치기하고 결국은 당신의 소지품을 유품 세일에서 사와서 직접 사진을 본다는 유쾌한 상상

  • 수많은 행렬에 대해 언급한 부분이 약간의 희망을 보여줌이라는 의견과, 존의 동생이 그 행렬들에 사람처럼 말하도록 가르친 방법을 찾아냈다고 이야기함

  • 연구자 블로그와 논문 링크 공유

  • 위 링크를 대학 보도자료에서 연구자 블로그 포스트로 바꿨음이라는 피드백을 남김

  • 새 취약점의 영향에 대해, 연구자가 CPU 전체 메모리 내용을 반복적으로 읽을 수 있어 초당 5,000바이트 속도도 가능하다고 설명하며, 결국 공격이 성공할 경우 CPU의 모든 정보가 유출될 수 있음

  • 블로그 링크로 제목 URL을 바꿔주면 좋겠다는 바람을 전함

  • 브랜치 예측자 동작에 대해 정리함

    • 브랜치 명령이 끝난 후에 예측자 상태 업데이트가 일어날 수 있음
    • 파이프라인 내에서 결과 커밋과 예측 커밋이 다름
    • 권한 변환 명령어도 예측 상태 대기 없이 파이프라인에서 진행되므로, 권한 수준이 일관되지 않으면 문제 생길 수 있음
    • 파이프라인에서 ‘현재 권한 레벨’이 단일하지 않을 수 있다는 점이 어려운 부분임

  • Kaveh Razavi 교수가 자신의 학교에서 하드웨어 보안 코스를 가르쳤었고 그 과정이 정말 멋졌음이라는 반가움

  • 몇 년 전 해당 과정과 맬웨어 관련 또 다른 강의를 확인하려 했으나 공개 정보가 거의 없었음, 공식 강의 녹화본이나 노트가 온라인에 있는지 궁금하다는 질문을 남김

  • Training Solo 공격과 이번 취약점의 관계를 아는 사람이 있는지 궁금하다고 질문

  • 칩셋 마이크로코드 패치에 대한 설명에서 윈도우만 언급하는 것에 의문을 가짐, 리눅스 사용자는 어떻게 되는지 질문함

  • 리눅스 커널도 오래 전부터 마이크로코드 로딩을 지원하고 있지만, 인텔에서 마이크로코드 파일을 배포해야 각 배포본이 업데이트할 수 있음, 시스템 업데이트에 포함되어야 한다는 설명

  • 인텔이 리눅스용 마이크로코드 업데이트를 github에 공개하고 있으니 각 배포본은 자동으로 거기서 받아서 배포가 이뤄짐, 해당 취약점이 실제로 패치됐는지는 전문가가 아니라서 잘 모르겠음이라는 설명

  • 인텔 공식 보안 권고 링크를 공유

  • AMD CPU에도 비슷한 취약점이 있는지 궁금하다는 의견과, 분기 예측과 같은 기술적 메커니즘이 CPU 보안 취약점의 근본 원인임을 지적하며 AMD는 어떻게 이런 취약점을 피하고 있는지 궁금함

  • 연구자 블로그 요약으로, 이번 Branch Privilege Injection 취약점은 AMD, ARM 시스템에는 영향을 끼치지 않는다는 답을 전함

  • AMD가 이런 문제를 완전히 피해간 게 아님이라는 요지와, 스펙터·멜트다운처럼 취약점마다 범위가 다르고 이번 건은 인텔 한정이지만, AMD도 같은 계열의 취약점(예: 스펙터)에는 노출된 적 있음

  • 약간 꼼꼼한 설명으로, 스펙 으로 추론 실행 자체가 취약점이 아니라 현대 CPU에서 필수적 메커니즘임을 강조, 내부의 결함이 발견되기 어려울 정도로 복잡해서, AMD와 ARM에도 유사한 버그가 있을 가능성 있음이라는 의견, 완전한 고치는 방법은 현대 시스템에서 코드의 격리가 불가능하다는 현실을 인정해야 하고, 이는 일부 대기업 비즈니스 모델에는 치명적임이라는 우려

  • 이 취약점의 대책으로, 브랜치 예측 업데이트 시점에 권한 레벨을 스냅샷처럼 저장하고 그 값을 함께 전달하면 소프트웨어에서 겪는 문제와 비슷하게 해결될 것 같음

  • CPU 분기 예측기가 버퍼 경계와 코드의 권한 정보를 바로 확인할 수 있다면 예방이 쉬웠을 텐데, 이런 정보는 포인터에 중요한 정보를 추가하는 작업이 필요함을 유쾌하게 지적함

  • 이슈의 범위를 더 명확하게 이해해야 한다는 의견이나, 스펙 으로 추론 실행을 통한 취약점 공격에는 실제로 엄청난 사전 준비가 필요하고 직접 코드 실행 권한이 있지 않으면 큰 의미 없음, 브라우저에서 임의의 JS 코드로 임의의 정보 유출은 불가능함, 자신은 성능 향상을 위해 모든 완화책을 비활성화함

  • CHERI 아키텍처를 추천함

  • 포인터 구조만 바꾼다고 될 일이 아님을 지적하며, 진짜로 하드웨어에서 각 메모리 접근에 주소 경계 정보를 부여하는 과거의 x86 세그먼트 방식(80286)을 언급, 그러한 시스템도 소프트웨어가 경계 정보를 정확히 다루어야 했지만 결국 동일한 한계를 가졌음

  • 지금 시점에서 모든 주요 운영체제에 해당 취약점에 대한 패치(혹은 관련 마이크로코드)가 적용되는지 확인 질문

  • 예스라고 답함, 정보 해금일이 오늘(5월 13일)임

답변달기