https://zombieloadattack.com/zombieload.pdf 2018년 1월을 뜨겁게 달구었던 Meltdown과 Spectre 취약점을 발표한 그 연구팀이, 비순차실행과 추측실행에 기반한 또다른...

Gepostet von Daniel Hong am Mittwoch, 15. Mai 2019

https://zombieloadattack.com/zombieload.pdf

2018년 1월을 뜨겁게 달구었던 Meltdown과 Spectre 취약점을 발표한 그 연구팀이, 비순차실행과 추측실행에 기반한 또다른 취약점을 발표했다. 공식 이름은 CVE-2018-12130, "대중적인" 이름은 ZombieLoad. 작년의 Meltdown과 마찬가지로 인텔 프로세서에서만 해당되는 취약점이며, AMD의 x86 프로세서나 ARM 프로세서 등에서는 해당사항이 없다.

ZombieLoad는 Meltdown보다 접근할 수 있는 메모리의 범위는 훨씬 작다. Meltdown은 커널에 의해 매핑된 가상 메모리 공간 전체를 덤핑할 수 있는 매우 광범위한 취약점인 반면, ZombieLoad의 경우 공격 시점의 프로세서에 실제로 로딩되어 있는 데이터에만 접근할 수 있기 때문이다. 매우 제한적인 취약점이라고 여겨질 수도 있겠으나, ZombieLoad으로 인해 클라우드 업계가 (작년에 이어) 또다시 뒤집어진 이유는 따로 있다.

먼저, ZombieLoad는 OoOE에 의해 (본래 접근 권한이 없음에도 불구하고) 이미 commit된 instruction이 오류를 내뱉으며 revert되는 과정에서 일어나는 sidechannel 기법을 사용하는 Meltdown과는 달리, *어떠한 권한오류 없이도* 데이터를 유출해올 수 있는 기법이다. 이는 Meltdown과 같이 커널의 메모리 공간을 격리하는 방식 등의 소프트웨어적 해결법을 *더 이상 사용할 수 없음을 의미한다.* 하드웨어 재설계 및 교체 없이는 완전히 막을 수 없는 취약점이라는 뜻이다.

또한, ZombieLoad의 경우 기본적으로 instruction pointer와 실제 데이터 로드/로드 해제 간 시차를 이용한다. 조금 더 구체적으로는, 실행 도중 fault 등의 상황이 발생하면 마이크로코드 레벨의 보호 로직이 발동해 현 로드 pipeline을 flush해 버리는데, (OoOE 계열의 취약점이 모두 그렇듯) 이미 실행 중이었던 명령어들의 경우 파이프라인의 flush 여부에 관계없이 그대로 실행을 마쳐버린다. 이 때, 연구진은 더 이상의 실행지연을 막기 위해 대응하는 물리 주소가 존재하기만 한다면 fill buffer에 남아있는 entry를 그대로 남겨둔다고 추측한다 (Meltdown 때와는 달리, 정확한 원인은 인텔의 엔지니어들만이 알고 있다). 따라서, 잘못된 (더 이상 유효하지 않은) fill buffer entry가 계속해서 남아 실행 프로세스가 계속되게 되는 것.

이 때, 인텔의 SMT 기법인 하이퍼쓰레딩은 최대한의 성능을 뽑아내기 위해 한 코어에 존재하는 모든 쓰레드에 fill buffer에 대한 접근권한을 제공하므로, *실제로 다른 쓰레드에 존재하는 코드라도* 같은 물리 코어에 있다면 상대 쓰레드의 데이터를 얻어올 수 있는 것이다. 이는 하이퍼쓰레딩뿐만이 아니라, 인텔의 프로세서 가상화 인스트럭션인 VT-x에도 적용되는 사항이다 (가상 머신 안팎의 데이터도 같은 방법으로 읽어들이는 것이 가능하다). 다시 말해, 대부분의 ZombieLoad 취약점에서 안전하기 위해서는 하이퍼쓰레딩도, 가상 머신도 사용해서는 안 되며, 이 두 가지를 모두 사용하지 않는다 하더라도 ZombieLoad로부터 완벽하게 안전할 것이라고 보장할 수 없다.

저 두 가지가 모두 필요한 업계는? 당연히 클라우드 업계다. 각 인스턴스에 최대한 많은 코어 수를 할당해주기 위해서는 하이퍼쓰레딩은 필수적이며, 그 가상 인스턴스를 돌리기 위해서는 당연하게도 VT-x에 의존해야 하기 때문이다. 거기다 가상 머신 간에서도 같은 일이 일어날 수 있으므로, 운이 나쁘게도 같은 프로세서에 악성 인스턴스가 단 하나라도 존재한다면 다른 가상 머신에 있는 데이터를 조용히 읽어올 수 있는 것이다. 클라우드 업계 입장에서는 그야말로 악몽이 따로 없는 일이다.

이야기는 갈수록 더 심각해진다. 연구진에 따르면, ZombieLoad는 공유된 userspace 메모리나 kernelspace는 물론이고, 인텔의 Software Guard Extension (SGX) 기능에 의해 보호되는 인스트럭션까지 영향을 줄 수 있다. 거기다 가상 머신 간, 혹은 가상 - 호스트 머신 간에서도 적용될 수 있는 취약점이니, 당연히 그냥 넘어갈 일이 아닌 거다.

여기에 대한 인텔의 공식 답변은? 허무하게도 간단하다. 인텔이 이 일에 대해 취한 조치는 엠바고가 풀리기 이전 마이크로코드를 수정해 앞서 언급된 보호 로직을 조금 더 개선한 것에 불과하다. MS와 애플은 각각 Windows와 macOS의 커널 레벨에서 추가적인 보호 로직을 추가했다. 그러나, 이러한 조치들은 ZombieLoad가 악용될 수 있는 "확률"을 줄여줄 뿐이며, 완벽하게 "패치"한 것이 아니다.

조금 더 완전한 보호를 위해서는 앞서 언급된 대로 하이퍼쓰레딩과 VT-x를 모두 비활성화해야 한다. 그러나 하이퍼쓰레딩을 비활성화할 경우 상황에 따라 최대 40%까지의 성능 저하가 있을 수 있으며, VT-x를 비활성화할 경우 가상화에 따른 일부 보안상 이점들까지 사라지기 때문에 모두에게 권할 수 있는 사항은 아니다. 실제로 인텔은 "대부분의 소비자들에게는 하이퍼쓰레딩을 비활성화할 것을 권장하지 않는다"라고 밝혔으며, MS와 애플 역시 "보안을 중시하는 사용자만 하이퍼쓰레딩을 해제하라"는 입장을 보이고 있다. 반면 구글은 긴급 보안 패치를 통해 인텔 칩을 탑재한 모든 크롬북 모델에서 하이퍼쓰레딩을 비활성화하는 조치를 취했다 (크롬북에서는 애초에 성능이 그리 중요하지 않으므로 큰 영향이 없기 때문에 내린 결정일 것이다).

그렇다면 인텔의 "대부분의 소비자"에 대한 권고사항은? "출처를 알 수 없는 소프트웨어는 절대 실행하지 말라"다 (https://www.intel.com/…/architecture-and-technology/mds.html). 거기다 공식 보도자료에서는 "이번 마이크로코드/소프트웨어 업데이트가 성능에 큰 영향을 미치지 않는다"는 사실만 내세우고 있다. 그 이상의 조치나 사과 같은 건 없었다. 출처를 알 수 없는 소프트웨어를 실행하면 안 된다는 걸 누가 모르나? 그 보안 수칙이 제대로 지켜지지 못하는 상황에서도 데이터를 보호하기 위해 프로세서의 수많은 보안 로직이 존재하는 것 아니었는지?

당분간 클라우드 업계에 이 일로 인한 후폭풍이 다소 클 듯하다. AMD 주가가 오르는 소리가 벌써부터 들린다. (...)