끝나지 않은 ‘CPU 게이트’… 스펙터의 변종, ‘렛블리드’ 공격 수법 발견

새로 발견된 공격 수법은 간접 jump 명령어 및 호출을 이용하는 스펙터와 달리 return 명령어를 악용한다. 
 

2018년, 인텔 및 AMD를 포함한 여러 CPU 제조업체를 큰 위기에 빠뜨린 ‘CPU 게이트’가 아직 끝나지 않은 듯하다. 최근 또 다른 방식의 ‘예측 실행(speculative execution)’ 취약점 공격 수법이 발견됐다. 예측 실행 공격이란, 최신 CPU가 속도를 높이기 위해 사용하는 예측 실행 기법을 악용하는 공격법이다. 시스템 커널 메모리에 보호되어 있는 민감한 데이터에 침투한다. 이 사건 이후 각종 보안 조치가 배포됐지만, 이번에 발견된 새로운 공격 수법은 스펙터(Spectre)나 멜트다운(Meltdown)과 달리 예측 실행의 다른 취약점을 노린다. 

이를 발견한 스위스 취리히연방 공과대학교의 연구소는 새 공격 수법을 ‘렛블리드(Retbleed)’라 명명했으며, 인텔과 AMD의 몇몇 프로세서가 위험에 노출되어 있다고 밝혔다. 구체적으로 인텔 프로세서의 경우 코어 6, 7, 8세대 모델이, (공식 취약점 번호: CVE-2022-29901) AMD의 경우 AMD Zen 1과 Zen 1+, Zen 2 모델이 취약점(공식 취약점 번호: CVE-2022-29900)에 노출된 것을 확인했다고 전했다. 취약성의 정도는 프로세서마다 모두 다르며 운영체제의 보안 구조에 따라 달라질 수 있다고 연구소는 덧붙였다. 

렛블리드은 어떻게 기존 방어책을 무너뜨리나? 
렛블리드는 2018년 1월에 발견된 스펙터와 비슷한 유형의 공격이다. 스펙터를 계기로 학계는 수년간 최신 CPU의 속도 향상 기법인 예측 실행의 보안 취약점에 대한 연구를 진행해왔다. 
 
기술에 대해 설명하자면, 예측 실행은 말 그대로 프로그램 코드의 실행 경로를 미리 추측하는 알고리즘을 CPU에 탑재해 성능을 높이는 기법이다. 이 알고리즘의 목적은 프로그램을 구동하는 코드가 조건부 명령어에 도달하기 전에, 실행 경로를 추측하는 것이다.  이로써 향후 실행될 코드 중 일부를 미리 처리하여 그 결과값을 CPU 캐시에 임시로 저장해둘 수 있다. 예측한 대로 프로그램이 경로가 진행된다면, 시스템은 이미 처리된 결과값을 바로 이용할 수 있으므로 프로그램의 구동 속도가 더 빨라진다. 이후 이 결과값은 바로 삭제된다. 문제는 바로 이러한 결과값에 시스템 커널만 접근이 가능한 민감한 데이터가 포함될 수 있는 것이다.

여러 연구진이 스펙터 같은 유형의 공격이 부채널 테크닉(side-channel technique) 같은 다양한 수법을 활용해, CPU가 특정한 코드 경로를 실행하도록 유도하여 민감한 정보를 드러내는 공격 기법을 쓴다고 밝혀냈다. 이외에도, 2018년부터 많은 연구를 통해 비슷한 방식으로 CPU가 일부러 잘못된 예측을 하도록 유인하는 스펙터의 다양한 변종이 있다는 것이 드러났다. 

인텔과 AMD는 이런 공격 수법을 완화하고자 하드웨어 기반의 보안 기능을 선보였다. 인텔은 처음 IBRS(간접 분기 추측 제한), 그리고 이후 향상된 분기 예측 제한(elBRS), AMD는 CSV2 완화 조치를 적용했다. 한편 구글의 보안 연구진도 소프트웨어 기반의 공격 완화 기법인 레트폴린(retpoline)을 공개했고 몇몇 운영체제와 하이퍼바이저 공급업체가 이를 도입했다. 

취리히대학 연구팀은 보고서에서 "jump 및 call 같은 간접 명령어를 악용하여 조건부 코드 분기의 예측을 방해하는 이전 공격 수법과 달리, 렛블리드는 return 명령어를 노린다”라고 설명했다. "이런 수법은 현존하는 Spectre-BTI(Branch Target Injection) 방어 기법을 우회하므로 매우 위험하다”라고 팀은 덧붙였다.

이 공격 수법이 위험한 이유는 구글의 레트폴린 완화 기법이 작동하는 방식에서도 찾아볼 수 있다. 이 기법은 jump 및 call 같은 간접 분기의 명령어를 return 명령어로 대체하는 식으로 익스플로잇을 방지한다. return 명령어는 보통 코드의 간접 분기에 쓰이지 않아, 예측 실행 경로에 포함되지 않기 때문이다. 그러나 취리히 대학의 연구팀은 return 명령어 또한 악용될 수 있다는 점을 발견했다. 심지어 이런 취약점이 예상보다 더 흔히 발생한다는 연구 결과를 전했다. 
 
보고서는 "인텔 프로세서의 취약점은, return 대상에 대한 예측 정보를 저장하는 반환 스택 버퍼가 언더플로(underflow) 될 때 return 명령어가 간접 명령어인 jump처럼 작동한다는 점이다"라며 "이는 CPU가 높은 수준의 호출 스택(call stack)을 처리해야 할 시 발생한다. 실험 결과 한 번의 시스템 호출이 1,000가지가 넘는 취약 조건을 일으킬 수 있다는 점을 발견했다”라고 기술했다. 
   
한편 AMD 프로세서의 취약점은, “return 명령어가 return 주소 스택의 상태에 관계없이 무조건 간접 분기처럼 작동한다는 것이다.” 보고서는 “만일 해커가 jump 같은 간접 명령어를 이용해 return 명령어를 악용해낸다면, AMD 프로세서의 분기 예측기가 return 대신 간접 jump 명령어가 실행되리라는 예측을 하도록 속일 수 있다. 이 말은 해커가 시스템이 호출하는 모든 return 명령어를 익스플로이트 해 민감한 데이터를 탈취할 수 있다는 말이다. 게다가 이런 return 명령어는 수없이 많다”라고 보고서는 기술했다. 
 
렛블리드, 미리 막으려면  
연구진은 리눅스 기반 운영체제를 겨냥한 공격을 시뮬레이션한 결과를 리숙스 커널 개발자 및 인텔과 공유했다. 리눅스 재단은 연구 결과를 기반으로 레트폴린 보안 패치를 손보고자 수정한 파일만 68개, 추가한 새 코드 라인의 수가 1,783개, 그리고 제거한 코드 라인의 수가 387개에 달했다고 전했다. 새로운 완화 조치는 또한 14%에서 39% 정도의 성능 저하를 일으킬 것으로 예상된다고 연구진은 덧붙였다. 

이는 마이크로 아키텍처상의 취약점이므로, 해당 공격 수법에 노출된 CPU 모델을 장착한 모든 윈도우 및 macOS 컴퓨터는 이론적으로 모두 잠재적인 공격 대상이다. 그러나 인텔은 공식 보안 권고에서 "윈도우 운영 체제에는 기본적으로 IBRS가 탑재되어 있어 업데이트가 필요하지 않다"라고 밝혔다.

한편 인텔은 렛블리드 공격을 ‘RSBU(Return Stack Buffer Underflow)’라고 명명했다. 회사는 새 개발자 지침에서 "IBRS(향상된 IBRS도 포함)를 활성화하면 RSBU 잠재적인 위협을 완화할 수 있을 것"이라고 언급했다. 

EIBRS는 일반 IBRS보다 성능이 뛰어나지만, 일부 구형 스카이레이크(Skylake) 세대의 CPU는 이를 지원하지 않는다. 따라서 애초부터 성능이 낮은 IBRS를 활성화하지 않은 채 소프트웨어 기반의 레트폴린 보안 패치만 적용한 일부 운영체제 공급업체 또는 가상 머신 관리자는 위험에 노출될 확률이 더 높다. 위에 설명한대로 레트폴린이 렛블리드 공격에 특히 취약하기 때문이다. 
 
인텔은 렛블리드 혹은 RSBU를 포함한 "단발성 공격"의 영향을 받는 CPU 모델의 목록을 업데이트했으며, 일부 CPU 모델을 위한 마이크로코드 업데이트를 제공할 계획이라고 밝혔다. 

한편 AMD는 렛블리드 같은 수법이 노리는 취약점을 이미 인지하고 있었다고 전했다. 회사는 이런 취약점이 AMD 엔지니어들이 ‘Branch Type Confusion(CVE-2022-23825)’이라고 명명한 마이크로아키텍처의 통상적인 취약 범위에 한 예시라고 설명하며 개발자 지침을 업데이트했다.  

젠(Xen) 및 시트릭스(Citrix)와 같은 하이퍼바이저 공급업체는 자체 권고 및 패치를 발표했다. 젠은 일부 AMD CPU 모델을 위한 보안 패치만 배포하며, "이미 인텔 및 AMD CPU를 위한 보안 패치 ‘XSA-254’ 및 차후 버전에서 업체 기준의 보안 조치를 적용했으며, 현재로서는 추가 수정이 필요하지 않다"라고 말했다.  

하지만, 이런 기본 보안 매치마저 그대로 적용하지 않은 관리자는 위험에 노출될 가능성이 있다. 시트릭스가 이번에 배포한 패치는 AMD Zen 1 및 AMD Zen 2 CPU에만 해당하는 보안 조치이기 때문이다. 시트릭스는 AMD Zen 3 및 인텔 CPU에서 실행되는 하이퍼바이저 소프트웨어가 렛블리드에 영향을 받지 않는다고 판단했기 때문이라고 설명했던 바 있다. ciokr@idg.co.kr, ethan_moon@idg.co.kr